Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:51028
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.45 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=NEE44EE9ktQNIJ1tUpyhjBvm3VeL77tbUaXDWHFqAj5UstSwZAb0C9sH3ARtA3ldQM
         yXg9VAEaNeYKGhIPINQi4w2eA/+Q29dyzF+gjeWaQhF7De9v8yxIwsL3fLPDgheUYu9l
         waN5mzPWw/nANNcFL7+w+AcKsr2wsduknF57I=
MIME-Version: 1.0
In-Reply-To: <4D07B7C8.8020506@verizon.net>
References: <AANLkTi=ixWQkKovKYuLuQckDvkLQY2nYEyG6PJfZAn-G@mail.gmail.com>
	<4D07B7C8.8020506@verizon.net>
Date: Tue, 14 Dec 2010 10:47:32 -0800
Message-ID: <AANLkTinzPKO_dvhfc1nQtRB3mAO6qR38f8Tcp70_v0nH@mail.gmail.com>
To: Gerry Reno <greno@verizon.net>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP Performance in Apache: Multi-Process vs Multi-Threaded
From: basant.kukreja@gmail.com (Basant Kukreja)

Hi,
I have spent a lot of time last year measuring php performance on
multi-threaded vs single threaded fastcgi.
I had used iplanet web server (instead of apache) for my measurement.  Out =
of
the box single threaded php apps were very close (better) than multi-thread=
ed
versions but when we started optimizing php for multi-threaded environment,
overall results were extremely positive (>35% faster than single threaded p=
hp
for an ecommerce apps).  There is a lot of scope of improving multi-threade=
d
php. Some of the areas we looked at are:
* memory management
* file operations (caching stats call etc.)
* Session data caching (memsession php plugin)
* Removing TSRMLS_FETCH for emalloc/efree
* Reduce malloc and replace with emalloc in various php code paths.
* Pre-compute hash values of string constants at init-time rather than
when processing a request.
* APC enhancement for multithreaded PHP apps.
* Using MPSS heap inside web server.


As far as multithreaded apps in production is concerned, entire java land r=
uns
inside multithreaded servers and runs very nicely. php however has never be=
en
optimized for multi-threaded web servers much so it runs lot nicer in singl=
e
threaded fastcgi environments.

Regards,
Basant.

On Tue, Dec 14, 2010 at 10:30 AM, Gerry Reno <greno@verizon.net> wrote:
> From our experience if you wish to serve any kind of PHP apps with
> internationalization using the popular GNU gettext system ( and right
> now there are many of these) then you must use a non-threaded webserver
> engine since GNU gettext library is not yet thread-safe (because GNU
> gettext process environment variables can be set by any thread which
> will drive the underlying GNU gettext library and these would affect
> every thread in the process).
>
> If you do not care about internationalization or using the most popular
> system for translations, GNU gettext, then you can choose any webserver
> engine type, threaded or non-threaded that your application will support.
>
> Personally, I would never run a threaded engine in production.
> Cross-thread contamination problems are most difficult to track down.
> And I prefer to have complete isolation between connections which makes
> it much simpler to track down problems. =A0The so far tiny difference in
> performance is outweighed by the isolation and debugging efficiencies
> obtaining using a non-threaded webserver engine.
>
>
> -Gerry
>
>
>
> On 12/14/2010 01:06 PM, Israel Ekpo wrote:
>> Hi All,
>>
>> I have a few questions about the performance of PHP web applications *un=
der
>> load* and I would appreciate if there is anyone that would like to share
>> their experiences in terms of any benchmarks or observations.
>>
>> *Background Information*
>>
>> In multi-process environments, such as FastCGI, Apache Prefork MPM etc, =
PHP
>> needs to execute the MINIT and MSHUTDOWN functions for all loaded extens=
ions
>> on every request.
>>
>> In a multi-threaded environment, such as Apache Worker MPM, with Zend Th=
read
>> Safety is enabled,
>> PHP only needs to execute MINIT and MSHUTDOWN functions once for each
>> extension and not each time a new thread is created to serve a request.
>>
>> It is also more expensive to create new processes than to create new
>> threads.
>>
>> In one-on-one comparisons between scripts executed only once in ZTS mode=
 and
>> scripts executed once in non-ZTS mode,
>> I noticed that the one in non-ZTS mode was slightly faster and this seem=
s to
>> be the main reason why most people go with the non-ZTS enabled setups.
>> But the reason for this slight difference in speed is because of the
>> differences in the data structure for globals for ZTS and non-ZTS modes.
>>
>> Other reasons people have cited for going with non-threaded setups inclu=
de
>> stability which I guess we should not really be concerned about if
>> non-threadsafe extensions are excluded.
>>
>> Since it is generally more expensive to create new processes than new
>> threads, I believe that under high load, php in ZTS mode (multi-threaded
>> environment) will perform better than an identical setup in NTS mode
>> (multi-process).
>>
>> *Problem*
>>
>> I noticed that Zend Server is using PHP in FastCGI mode (multi-process N=
TS)
>> and I am contemplating setting up apache in worker mode (threaded mode) =
and
>> compiling php in ZTS mode instead.
>>
>> Has anyone performed any load tests benchmarks comparing the two setups
>> (Multi-Process vs Multi-Threaded)?
>>
>> Are there PHP extensions that cause issues in threaded environments that=
 I
>> should avoid?
>>
>> Are there any internals information or any other reasons why I should ch=
oose
>> ZTS over NTS or vice versa?
>>
>> Any useful feedback will be highly appreciated.
>>
>> Thanks.
>>
>>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>