{"id":3939,"date":"2012-12-05T12:17:49","date_gmt":"2012-12-05T16:17:49","guid":{"rendered":"http:\/\/www.webperformance.com\/load-testing-tools\/blog\/?p=3939"},"modified":"2018-08-09T08:24:16","modified_gmt":"2018-08-09T12:24:16","slug":"setting-apache2-ulimit-for-maximum-prefork-performance","status":"publish","type":"post","link":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/2012\/12\/setting-apache2-ulimit-for-maximum-prefork-performance\/","title":{"rendered":"Setting Apache2 ulimit for Maximum Performance"},"content":{"rendered":"

As strange as it seems, when you start up the standard RedHat or CentOS release, it is not configured for running Apache2 with any sort of performance! In fact, even on a large server you’ll be lucky to handle 100 concurrent users on even simple web pages. So many websites have very few visitors so often its not noticeable, but even if you adjust all of the other apache2 settings<\/em>, if you don’t bother to adjust the ulimits, the site will be handicapped by really bad performance.<\/p>\n

\n \n
\n

Web Performance Consulting<\/h2>\n
\n
\n Our experts find out how many users your website<\/strong> can handle!
\n <\/span>
\n  
\n Learn More<\/a>\n <\/div>\n<\/p><\/div>\n<\/p><\/div>\n

First, in running the tests I decided to stick with the default prefork MPM. There’s dozens of sources on the web for configuring Apache prefork for maximum performance that I won’t repeat here. Typically, though, the first thing to do is set a high number of MaxClients, which really isn’t that high considering a “client” is a socket connection, and modern browsers can open eight socket connections at a time. This turns the “8192” below into only 1,024 actual concurrent users. Of course its possible to set MaxClients higher than that, but with a typical test scenario only 500 clients can potentially max out the available bandwidth and CPU, so this isn’t a bad place to start:<\/p>\n

StartServers 20
\nMinSpareServers 25
\nMaxSpareServers 100
\nServerLimit 8192
\nMaxClients 8192
\nMaxRequestsPerChild 10000<\/p>\n

<\/code>
\nSo, what type of performance do you get with these settings? The testcase I used was browsing our company website, configured as static pages, with 4 second think times and a page-load goal of 2 seconds per page. Even though it should have been able to handle at least 512 browsers, the webserver started crashing at less than 100 concurrent users.<\/p>\n

\"\"<\/p>\n

As it turns out, despite setting MaxClients to 4096, the system never actually reaches that level because the compiled in limit for the number of processes is 1024, as can be seen below:
\n
\n[root@faith ~]# ulimit -a
\ncore file size (blocks, -c) 0
\ndata seg size (kbytes, -d) unlimited
\nscheduling priority (-e) 0
\nfile size (blocks, -f) unlimited
\npending signals (-i) 59400
\nmax locked memory (kbytes, -l) 64
\nmax memory size (kbytes, -m) unlimited
\nopen files (-n) 1024
\npipe size (512 bytes, -p) 8
\nPOSIX message queues (bytes, -q) 819200
\nreal-time priority (-r) 0
\nstack size (kbytes, -s) 10240
\ncpu time (seconds, -t) unlimited
\nmax user processes (-u) 1024
\nvirtual memory (kbytes, -v) unlimited
\nfile locks (-x) unlimited
\n<\/code>
\nThe fix on RedHat\/CentOS is to edit the file \/etc\/security\/limits.conf<\/code> and these lines, adjusting the limits based on your system capacity and needs.
\n
\n* soft nofile 10240
\n* soft nproc 10240
\n<\/code>
\nRestarting Apache and Re-running the tests resulted in a huge increase in performance, increasing the capacity of the server to around 600 concurrent users.<\/p>\n

\"\"<\/p>\n","protected":false},"excerpt":{"rendered":"

As strange as it seems, when you start up the standard RedHat or CentOS release, it is not configured for running Apache2 with any sort of performance! In fact, even on a large server you’ll be lucky to handle 100 concurrent users on even simple web pages. So many websites have very few visitors so often its not noticeable, but even if you adjust all of the other apache2 settings, if you don’t bother to adjust the ulimits, the site will be handicapped by really bad performance.<\/p>\n

Web Performance Consulting<\/p>\n

… Continue reading »<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[34,8],"tags":[],"class_list":["post-3939","post","type-post","status-publish","format-standard","hentry","category-apache-httpd","category-load-testing"],"_links":{"self":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/3939","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/comments?post=3939"}],"version-history":[{"count":31,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/3939\/revisions"}],"predecessor-version":[{"id":3974,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/posts\/3939\/revisions\/3974"}],"wp:attachment":[{"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/media?parent=3939"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/categories?post=3939"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.webperformance.com\/load-testing-tools\/blog\/wp-json\/wp\/v2\/tags?post=3939"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}