Calvin, “Performance” with apache, just as is in the bedroom, is a relative/subjective term shrouded in myth and legend. I say relative/subjective because “performance” depends on who is measuring, what is being measured and the task underlying these measurements. Facebook’s perception of performance does differ from that of Safaricom.co.ke though you can bet, in a downtown bar, both sysadmins will throw the word around boisterously. The short of it is that it is not a discrete science. There are no absolutes! The long of it is that there are many variables that affect performance, and your first step in treatment is to find out where one is “lacking” – of course after accepting there are “performance” issues to be addressed. Consider the following typical “performance” killers: i) Congenital disorders: Your application is poorly designed; right from DNA, upwards is mbaya & mboff. ii) Systemic diseases: Your application strategy is computationally expensive and degrades exponentially with a slight increase in load. An example is a PHP for-loop that counts to 100,000 on each request; This will run acceptably for 10 concurrent users but might significantly degrade for 1000 concurrent users iii) Diet: Poor supply (or absorption) of server nutrients like RAM, Bandwidth etc iv) Excessive Weight: Your application responses and/or backend activities are excessively bloated; try reducing these to query, render, serve. Store JavaScript & CSS in minified form and gzipped if possible. Side Note: On this, I STRONGLY maintain it is strategically wrong to carry out repetitive computations on each request as opposed to offloading much of this as is possible to when the data goes into the database. (@Michael Pedersen: are you reading this? J) v) Lousy Partners: Here you place rogue systems and those hackers being hired all over the place. Unfortunately, short of divorce by pulling the cable your only recourse is to learn to live with it. vi) Use Performance Enhancers: Consider bytecode compilers/encoders/accelarators like eAccelarator, XCache or php_apc for PHP. I recommend eAccelarator but on a multi-instance apache setup it seems to misbehave, nothing life-threatening though… vii) Environment: Your application can only get so much out of a 16-bit 286 box Side Note: AMD Interlagos processors have up to 16 cores for under $600 and ASUS Dual CPU boards for approx $400 supporting up to 512GB RAM anyone out there who has had the nerve to try this assembly on DIY basis? While not seeking to slight what it is you are doing, I have seen apache serving in excess of 500 requests a second at peak times with pretty much default settings and a CPU load of less than 30% with database, dns and mail servers on the same box (an Acer desktop) with the good old Windows XP. By web standards and apache deployments out there, this box and load amounts to a small toy, hence my serious doubt that apache is your problem. You are bound to hit other bottlenecks way, way before apache’s default settings become an issue. While requests per second is an important metric to measure, you should be more concerned with the duration per request – how long does it take from the time you receive a request to the time you return a response at the application level. When you get to that side of the world you will realize that apache or its cousins nginx/lighthttpd (even IIS) are least of your problems – typically a http server’s processing constitutes less that 5% of the request’s duration. I stand to be corrected, but I find it unlikely that for a php application that intrinsically takes 1000 milliseconds to process a request under apache will suddenly speed up to serve the same request in 50ms when switched to nginx. Figures floated around the net seem to suggest that apache can do upwards of 6000 requests a second whereas nginx is capable 9000. I have not experienced either nor can I say the figures are authentic, but trust you me on this one: at 1000 requests per second (all http servers out there can do this) your concerns will be way beyond squeezing an extra 10ms from your http server. Assuming a modest average response size of 5kb, at 1000 requests a second you will need uplink bandwidth upwards of 40mbps… Locally, not even NMG with a combined suite of most popular sites are halfway up at that scale, is your application at that level? That said, here are a couple of optimizations you could look at: a) Assuming your issue of performance relates to sluggishness: i) RAM can never be enough, but first move to 64-bit hardware and OS platform. 32-bit systems have an implicit limit of 2GB per process. Intel released some magic called PAE that raises this limit to 3GB but I doubt apache is by default compiled to take advantage of those extensions. Go figure out from the source code and good luck J. The 2GB/process limit may not apply if you are running apache with the prefork mpm. Get PAE details here: http://en.wikipedia.org/wiki/Physical_Address_Extension ii) Use mod_deflate to reduce up to 70% of your bandwidth. Additional strategies here are using proxy servers like squid to shield your apache deployment iii) Use mod_expires to instruct in-transit and browser caches not to keep requesting content that does not change frequently iv) KeepAlive directive: Reduce (or eliminate) keep alive. I find that KeepAlive set to 3 to be optimal than the default 15, but you may need to experiment with this by looking at your analytics in terms of the average stay on a page and number of resources required to load a page completely. Rational here is that higher keep-alive values unnecessarily tie up resources on the server without necessarily adding benefit to page load times v) Timeout directive: lower this value from the default of 300 to something like 30 but beware of your folks on slow connections, rationale is the same as for keep alive vi) Separate your dynamic content from static content. Dynamic content suffers from RAM hogging owing to your scripting environment (whether NGinX, LightHTTPD, Apache or IIS – the difference is the same). Problem here is that worker threads allocate RAM but never release it back to the OS when finished even if serving the next request will require less RAM than is allocated. (ironically this is done for performance reasons). You could consider the MaxRequestsPerChild directive to force killing of workers after a certain number of requests to reclaim RAM – also useful if you suspect there is a module leaking memory. Static content on the other hand benefits from OS facilities for memory mapping frequently accessed files. Static content ought to be stored in pre-compressed format (gzip) for direct serving without having to commit the server’s resources to compress these at each request vii) Combine your JavaScript and CSS files into as few as possible per page. Combine your images – especially applies to those numerous small images/icons used for madoido. Set the expires header far into the future viii) Of course your disk RPMs do matter but I find this an over kill. Am told a raid 5 disk setup can also speed up things significantly but am yet to personally measure this. I prefer to avoid disks altogether and majorly run applications based on a RAM cache. b) Assuming your issue of performance relates to number of concurrent requests i) Raise the MaxClients directive to something like 300 and ThreadsPerChild to something like 50. Experiment this with your heaviest script with respect to RAM (remember you have a 2GB limit on 32 bit systems) on NT based systems only ThreadsPerChild applies, set it to something like 400. Caveat here is that when apache runs out of ram during a request, it returns a HTTP error 500. On thread-based systems, it hangs and users get a WSoD ii) A more advanced - but simple J (sic) alternative is to setup apache load balancing by instantiating several instances of apache on the back end as workers, each with default settings but running on different ports and setup another apache on port 80 in reverse proxy facing the web. Here you will need mod_proxy and mod_load_balancer modules. The web-facing apache should be stripped of all modules (especially those related to scripting like mod_php or mod_perl) so that its ThreadsPerChild, MaxClients and MaxRequestsPerChild can be increased significantly without hitting RAM issues All said and done, you ought to know your actual application metrics per cluster of users. Things like average bandwith per batch of say 100 users, RAM/CPU utilization at low,normal and peak load times etc. If all the above is implemented but fails, then you have a very good and disirable problem. You have massive traffic (and assuming dollars to boot). Setup a server farm and go for a layer 4/7 load balancer. I would recommend a unit from KEMP technologies. Lastly, as a rule of thumb, in my experience, if the server does below 300 requests a second at peak load, I had rather play pacman than bother tweaking configs Hope this helps. Regards Outstanding Online Investment Content Provider 2009 – Computer Society of Kenya From: skunkworks-bounces@lists.my.co.ke [mailto:skunkworks-bounces@lists.my.co.ke] On Behalf Of Odhiambo Washington Sent: Wednesday, July 11, 2012 4:41 PM To: Skunkworks Mailing List Cc: calvine_barongo@yahoo.com Subject: Re: [Skunkworks] IMproving perfomance of a Lamp Server Names!!! On Wed, Jul 11, 2012 at 4:36 PM, Dennis Kioko <dmbuvi@gmail.com> wrote: Let me invite the wrath of dragons and old school gospel adherents with the following. If you are getting Apache can't handle your load with the current resources, and do not have any reason you really want to use Apache, you may as well replace it with Nginx. Call me names now, thank me later. _______________________________________________ Skunkworks mailing list Skunkworks@lists.my.co.ke ------------ List info, subscribe/unsubscribe http://lists.my.co.ke/cgi-bin/mailman/listinfo/skunkworks ------------ Skunkworks Rules http://my.co.ke/phpbb/viewtopic.php?f=24 <http://my.co.ke/phpbb/viewtopic.php?f=24&t=94> &t=94 ------------ Other services @ http://my.co.ke -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ I can't hear you -- I'm using the scrambler.