It’s now over a year since I wrote about “Exchanging apache2-mpm-prefork for apache2-mpm-worker, and using php5-cgi on Debian to improve performance“. Since then I have re-evaluated my opinion about running apache2-mpm-worker and php5-cgi on a low memory machine, specifically a virtual machine running under Xen, running Debian.
There are some seemingly positive things with apache-mpm-worker and php5-cgi:
At little to no web traffic load:
- fast response time
- low memory usage
When traffic load is low (none or few people visiting your sites) the memory usage is very low when using apache2-mpm-worker. This is of course because it doesn’t have the php-interpreter loaded as a module, but also because of other things. When a dynamic site is accessed, and php5-cgi is launched to process your php scripts, it gets done quite fast if there just is enough memory for the process.
Here we come to the biggest problem with this though; when there is a little more visitors, to dynamic content, php5-cgi processes are spawned too fast, and does not have time to finish, more and more memory, and swap, are being allocated, until the webserver goes on its knees, and ends up killing off the php5-cgi processes, or you have to manually kill them, which will drop any connections, from possibly search engines. If you are unlucky you can not even type the kill command in, or atleast have to wait 5 to 10 minutes for it to show up, and execute.
This might be controllable if you configure Apache to run very, very few threads, in mpm-worker, but.. then one is really better off using mpm-prefork, it gives you much harder and better control over how many processes, and visitors, that can be served simultaneously.
I recently switched back to mpm-prefork instead, and pulled down the number of simultaneous connections being served drastically. This probably has the effect of all my sites running “slower”, in the appearance to my visitors, but, it is only slow, even if it is to everyone, atleast it doesn’t drop connections, and completely renders my webserver unusable, at higher visitor loads.
The difference between mpm-worker and mpm-prefork is that mpm-prefork waits until the php-script has been processed, if using the php module that is, which is the most common, while mpm-worker answers the request, then forks off to php5-cgi, and answers another request. I think that is what it does, even if you have the number of threads set very low. It does not wait for php5-cgi to finish no matter what you do. In a low-memory situation, this is bad. I thought it was an advantage to use mpm-worker before, now I do not.
Like I’ve stated in my earlier post, getting more memory really is the only good solution, but again.. this makes me survuve a little longer with this. Below is my current configuration. Feel free to comment and let me know your opinion or experience of simillar situations.
# prefork MPM # StartServers: number of server processes to start # MinSpareServers: minimum number of server processes which are kept spare # MaxSpareServers: maximum number of server processes which are kept spare # MaxClients: maximum number of server processes allowed to start # MaxRequestsPerChild: maximum number of requests a server process serves # # beardy, default 5 StartServers 1 # beardy, default 5 MinSpareServers 2 # beardy, default 10 MaxSpareServers 3 # beardy, was 150 MaxClients 6 # beardy, was 0 MaxRequestsPerChild 4000 #
This is only my experience, and your mileage may vary. But I have dealt with this for over a year now, and I think that gives my opinion atleast some substance. As you can see above, I only serve a very, very low amount of visitors simultaneously, but like I said, atleast everyone gets served, if they have a little patience, instead of having every request crawl to a halt, and then get killed. Foremost, search engines are not dropped. (Some crawlers have a high impact occassionally. This is very notable if one uses WordPress for instance, and crawlers pick up new content quickly.)
Since there seems to be some readers of my previous post on this topic, I wanted to share this revised (and current) view as well.
Other writings and opinions by other people on this subject: