Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:58253
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain punkave.com designates 209.85.210.170 as permitted sender)
Received-SPF: pass (google.com: domain of tom@punkave.com designates 10.50.216.231 as permitted sender) client-ip=10.50.216.231;
MIME-Version: 1.0
In-Reply-To: <CAORXhGK7mpqz-A6fWpeMnwodcp7iJ+-1JYqECD8xTjSYY4oz4g@mail.gmail.com>
References: <CAORXhGJWoLbLgX4ur_CuYpj7J28srgBtcO7uTnM5Wt5SYwKD9w@mail.gmail.com>
	<5a1d155ad465d1ec2e6461f5347d859f.squirrel@www.l-i-e.com>
	<CAMUwpuS+17YjUzpZ7PYj-G4Bh6NjqkH-ZN2zOcC_J9JXRrQqUw@mail.gmail.com>
	<4F4BF1C6.8010104@rowe-clan.net>
	<CAORXhGJg0n7Voknbh7SUdxGureM6jZVk+8nLmP=suWSYwBDvXw@mail.gmail.com>
	<CAMUwpuQGRQpMabrPXf2SE6OQhwPBLtsqGsVBBzS0NhgwwYwGqA@mail.gmail.com>
	<CAORXhGK7mpqz-A6fWpeMnwodcp7iJ+-1JYqECD8xTjSYY4oz4g@mail.gmail.com>
Date: Tue, 28 Feb 2012 11:15:55 -0500
Message-ID: <CAORXhGLj6MFX7KnHi8WucA4d3+VWPQ5R5CRgKU802DKgU7KUsA@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] pecl, zts, non-zts, fastcgi and Apache
From: tom@punkave.com (Tom Boutell)

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 <jpauli@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