Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65393
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain zend.com does not designate 209.85.214.182 as permitted sender)
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> <CAEZPtU79ULd3r_ArJE2gsmnCYcDV8UBmXevXmLMB-QMDiFN+CA@mail.gmail.com>
In-Reply-To: <CAEZPtU79ULd3r_ArJE2gsmnCYcDV8UBmXevXmLMB-QMDiFN+CA@mail.gmail.com>
MIME-Version: 1.0
Thread-Index: AQJJdUzE2iPwKiwvzciYvchG03LAWgHrKhe1AkgXmvEAyNLsagInIOvjAjNe6uACi4oZMwH0VTMxAfvbstQBoGVPgZbd0fvA
Date: Tue, 29 Jan 2013 16:14:13 +0200
Message-ID: <8d28541da15bbea04048c41051fe0f09@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Cc: =?UTF-8?Q?Johannes_Schl=C3=BCter?= <johannes@schlueters.de>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PHP-DEV] ZTS - why are you using it?
From: zeev@zend.com (Zeev Suraski)

> -----Original Message-----
> From: Pierre Joye [mailto:pierre.php@gmail.com]
> Sent: Tuesday, January 29, 2013 3:19 PM
> To: Zeev Suraski
> Cc: Johannes Schl=C3=BCter; PHP internals
> Subject: Re: [PHP-DEV] ZTS - why are you using it?
>
> 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=C3=BCter; 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.

It is too negligible.  Once the pages get allocated and mapped properly -
it's exactly the same thing as accessing memory.
Locking in between processes is indeed slower than locking inside
processes, but at the risk of sounding like a broken record, in something
like an opcode cache (few writes, mostly reads), it's negligible.

> > For example, you could say that thread-safe PHP would be 2x faster.
> > Or 2x 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).

OK, now we're getting somewhere.  So ESENT is one legit use case that
would benefit from a multithreaded PHP.

> > 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).

Which ones?

> 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.

Not recently.  But I'd be surprised if it wasn't equivalent at least as
far PHP is concerned.  Nginx is marginally faster in pure PHP performance
than Apache;  Where it really shines is that it can do it with fewer
processes -> much less memory consumption.  That attribute stems from
breaking the 1:1 mapping and turning it into an n:m mapping.

> It could have been the wrong path for some situation back then, but it
is
> definitively not wrong to improve thread safety.

I didn't suggest that.  My original question was 'Why do you use
thread-safe ZTS'.  It was explicitly not an RFC to stop developing or
remove ZTS mode.

I do think that we'll do our users a much better service if we tell them
that unless they have a very good reason to use a web server plugin on a
multithreaded server, they should use FastCGI instead.

> > 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.

Well, it wasn't my intention, at all.  I was genuinely surprised there was
a high level of interest about ZTS when we discussed Optimizer+, which
made me wonder why that is the case.

> > 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 :).

I think that properly configured FastCGI will be superior to a
server-plugin in mostly every way.  The one downside is that you lose the
server-specific features, but that's typically not a huge price to pay.

Zeev