Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65375
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.49 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <a32078ada7f92074e632e1540f3cc480@mail.gmail.com>
References: <d0d4398d8ad51ffa330d9d960bcd91a5@mail.gmail.com>
	<CAEZPtU7Pass+ogTJy5iBQpHARdNycXw8aMWxi=MkvZENw=hiwg@mail.gmail.com>
	<e8cf5bb937155b161076584852de6753@mail.gmail.com>
	<CAEZPtU4_8Eh2j6JkSqY883jM--_i+b=PABbdrxKFqPaQGht9Bg@mail.gmail.com>
	<1359459921.3916.105.camel@guybrush>
	<CAEZPtU7wP0O4rfeSfQV9Ct6wGWSy2kgUCWxEybFY7-Bx9tLoqA@mail.gmail.com>
	<e8a5168ec3aa2d291a8561552cb3d4bb@mail.gmail.com>
	<CAEZPtU5VZnGyGwH7kqFpCrHC-9A5PAmw-VmdZF7rV_0Zn-WkwQ@mail.gmail.com>
	<a32078ada7f92074e632e1540f3cc480@mail.gmail.com>
Date: Tue, 29 Jan 2013 14:18:35 +0100
Message-ID: <CAEZPtU79ULd3r_ArJE2gsmnCYcDV8UBmXevXmLMB-QMDiFN+CA@mail.gmail.com>
To: Zeev Suraski <zeev@zend.com>
Cc: =?ISO-8859-1?Q?Johannes_Schl=FCter?= <johannes@schlueters.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] ZTS - why are you using it?
From: pierre.php@gmail.com (Pierre Joye)

On Tue, Jan 29, 2013 at 1:52 PM, Zeev Suraski <zeev@zend.com> wrote:
>> -----Original Message-----
>> From: Pierre Joye [mailto:pierre.php@gmail.com]
>> Sent: Tuesday, January 29, 2013 2:19 PM
>> To: Zeev Suraski
>> Cc: Johannes Schl=FCter; PHP internals
>> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>>
>> On Tue, Jan 29, 2013 at 1:06 PM, Zeev Suraski <zeev@zend.com> wrote:
>>
>> >> It is inter process sharing and is very expensive, nothing to compare
>> > with shared
>> >> memory within a single process, accross many threads.
>> >
>> > What are you basing that assertion on?  Shared memory should have
>> > identical performance to regular process memory.  It's mapped in very
>> > similar way.
>>
>> Testing maybe?
>
> Retest then, you've got it wrong.  Shared memory (or memory mapped files
> as they'd be on Windows) are simply memory, it's available to the process
> in exactly the same way and while the OS does slightly different
> book-keeping for it in how it populates the pages - it's negligible.

It is not negligible, also the locking is different. Also, if I
remember correctly there is no rwlock support either, which is a huge
cons.

>> No, we can't. The main reason of the bugs and performance issue is due
> to the
>> current implementation and how extensions developers have to deal with
> it. It is
>> not separable from discussing what could be the worst decision we ever
> made,
>> droping thread safety.
>
> Well, I'm not interested in discussing the implementation when the need
> isn't clear to me.

> For example, you could say that thread-safe PHP would be 2x faster.  Or 2=
x
> more memory efficient.  Or will enable us to do XYZ which we otherwise
> can't.

There are quite a few things I can do on Windows only in thread safe
environments (f.e. ESENT, builtin DB, used by AD for example, damned
fast).

> For now, an *utopian* ZTS mode would, at best, not give us anything.
> Even if we put aside the performance/reliability issues - why would
> someone want that mode over other modes?

I must be really unclear or something along this line. Alone on IIS,
there are dozen of features you can't do nor use using fastcgi. Apache
could also be used in a better way (windows here too, linux has a
module for both builds of apache).

btw, have you tried to compare IIS/FastCGI (I won't even try with
apache+fastcgi) on Windows vs nginx-fpm on linux? I would be very
surprised if your numbers show that they are equivalent.

> Pierre, I'm sorry, but when you state something like '[shared memory] is
> inter process sharing and is very expensive', there's no other way to
> describe it other than a myth.  Better theoretical performance is a
> misconception.  The best PHP performance/density available today is on
> nginx, which couldn't be farther away from
> multithreaded-PHP-in-process-arch.
>
> Even after what you just said, you've yet to bring up a single reason for
> why one would want to use ZTS inside a web server context.  You seem to
> love ZTS with a vengeance but you can't quite explain why.  My 'company'
> didn't decide anything regarding ZTS.  It was me, probably the person wit=
h
> the most experience with ZTS back in the day, and it was probably much
> more difficult for me than anybody else to realize that the ZTS approach
> was the wrong path to go to as it was my baby project.

It could have been the wrong path for some situation back then, but it
is definitively not wrong to improve thread safety.

I would rather have one single build instead, and enable the ts
related stuff when necessary. It will add some more functions in the
engine but it would be much more clear and easier than what we have
now.

> BTW, for the love of [insert here], I'm not talking about killing thread
> safety.

That's how it looks and that's where this discussion is going, tbh.

> It's useful for long running processes, and who knows, maybe in
> the future we'll have threads inside PHP.  But I *am* talking about
> telling people that using ZTS in production is not recommended and that
> they should be using FastCGI instead.

As far as I remember, we already do that for a couple of web servers.
And in the long run, I will rather tell not to use FastCGI for
dedicated hosting and the likes. That being said, I also met many ISPs
which are not happy with the all-fastcgi, memory usageand performance
were the issues (have to read my backlog for other details :).

Cheers,
--
Pierre

@pierrejoye