I did check out the article on using worker thread MPM with PHP on Linux. The basic argument is that since threads can reclaim memory used and then freed by other PHP requests, while processes don't return memory to the OS until they finally exit, there is more memory available.
However I doubt that this can be the case when the server is at peak utilization. When things are maxed out you will still have, say, 20 threads hitting PHP scripts that happen to be expensive in terms of memory (let's say 50mb), and that will be roughly all the memory you have to play with in your 1GB system. So you're just as stuck as if you had 20 dedicated fastcgi processes, all maxed out at 50mb already by some previous request. The only win here is that in the average case, you can handle more requests. But you usually can't predict in advance when the worst case will come along. So if you permit that to happen you are risking a slowdown or a meltdown (: For stability a fastcgi pool of the size you know you can handle based on studying your past memory stats still seems to be the way to go. > On Tue, Feb 28, 2012 at 10:41 AM, jpauli <jpa...@php.net> wrote: > >> Actually, the true story for performance is to kill Apache and let Lighttpd >> or NginX do the job, with a pool of fcgi/fpm PHP processes > > I'd like to ask you whether it really makes much difference to use > Lighttpd or NginX as opposed to Apache with the worker thread MPM, but > at that point we are officially way off topic (: > > I think that in terms of general architecture, and in terms of what to > do with PHP, those three options are basically the same option. > > I haven't studied FPM yet as I haven't felt a need for its advertised > advantages over the traditional FastCGI support in the CGI SAPI yet. > > I will check out the apache worker and PHP article, thanks. > > -- > Tom Boutell > P'unk Avenue > 215 755 1330 > punkave.com > window.punkave.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
