That referenced page is for a machine with a GB of RAM, and the suggested MaxClients of 250 is going to cause real problems for probably all but the largest Linodes. To be honest, I think the settings are probably too high even for that machine. For example, if I'm reading it right they limit PHP to 64MB of memory, which means that even without the Apache process overhead, at 250 simultaneous clients they risk needing like 16GB of memory worst case. Of course, in practice most PHP requests likely use a fraction of that memory which is how they get away with it at all.
Once you overcommit memory heavily and start thrashing on a VPS, performance is going to tank. The odds are good that during your stress test, you're forcing your Linode to start so many Apache processes in parallel that you're swapping heavily and everything essentially comes to a stop while waiting for all the I/O to complete.
There are a large number of Apache tuning threads here in the forum (searching for MaxClients might be a good start) that you might try reviewing.
Certainly if you're on a Linode 512, just for the heck of it, drop MaxClients down to 15-20 or even lower to start with and see how it does. Watch peak memory usage during the stress tests.
Peak transaction throughput may suffer at that low value, but you shouldn't keel over completely at any point and if you find yourself with spare working memory under load, you can start raising the value, and start playing with requests per child and so on. PHP caching is definitely also worth pursuing. But MaxClients is the single big knob that should at least let you get into the ballpark in terms of resources.
Last time I tried this myself (Linode 512 with Apache fronting a Silverstripe CMS site over mysql), I settled on about 25 for MaxClients for testing with absolutely no other PHP or mysqld tuning. My apache processes were averaging about 16-18MB in resident size, and I was getting 20 requests/s. The system floated with around 50-75MB free during the test. The processing was entirely CPU bound, so Apache's requests per child configuration made little difference, but I could keep churning 20 requests/s as long as needed.
Now there's a variety of things I could do to try to increase the processing rate, but increasing MaxClients would
not be one of them. Even just going above 30 pretty much guaranteed I'd thrash and performance would absolutely tank. But, for example, I tried with 50, and ended up going from almost 100% cpu bound, to almost 100% I/O wait bound and no free memory. My transaction rate during tests dropped to 3/s (an 85% drop) and 72% of 200 test transactions failed to complete. I even generated a kernel panic when the machine OOM'd without finding a killable process (I had only configured 256MB of swap). All from changing MaxClients from 25 to 50.
It's useful to note that MaxClients keeps memory usage in check, but even low settings can deliver high request rates as long as the page processing is fast and memory could in theory permit a higher value. For example, static content through the same system (no PHP used by the page, resident apache process size around 4-6MB) was about 6000 requests/sec. I had a lot more free memory during the test, but even without leveraging all of it got decent rates.
Hmm, this got pretty long - I was originally just going to say "drop MaxClients"
-- David
FAQ
Search
Members
Register
Login [ Anonymous ]
