Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104428
MIME-Version: 1.0
References: <BYAPR02MB5766B8D8FCE674BF544B7FB0BF660@BYAPR02MB5766.namprd02.prod.outlook.com>
 <d9464082-3839-c51a-6591-e0ed2b6d4201@gmx.de> <CALKiJKqFsN5R8b7i=t3QyT-vC-0pcsOYD=G6taXXBVDuSjkcQw@mail.gmail.com>
 <1882693.l3SFSfi3S3@vulcan> <CAJHtznxu41gQTKRTGOC4iEP_5nJXbMAfKNTN6APcegA74rfa8A@mail.gmail.com>
In-Reply-To: <CAJHtznxu41gQTKRTGOC4iEP_5nJXbMAfKNTN6APcegA74rfa8A@mail.gmail.com>
Date: Fri, 15 Feb 2019 09:33:47 +0700
Message-ID: <CAEZPtU5RBVoAyvXh+1qGruHX85eGtadAdM7GWPOz+We=sU3Mpg@mail.gmail.com>
To: Zeev Suraski <zeev@php.net>
Cc: Larry Garfield <larry@garfieldtech.com>, Internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: ZTS improvement idea
From: pierre.php@gmail.com (Pierre Joye)

Good morning,

Again a long reply from me, sorry :)

There are a few things I would like to clarify from my perspective.On
Windows, historically (for years), the only usable webserver was
Apache. And the only way to work with it for years as well was
mod_php. Given the Apache's design, it requires thread safety. As Zeev
mentioned, ZTS was created to bring a thread safety framework for the
engine and the extensions. It did not get updated for years and relies
on old APIs or ways of doing it. On Windows the performance impact was
even bigger.

With the introduction of thread local storage support introduce
(https://wiki.php.net/rfc/native-tls) things improved drastically. TLS
solves many issues we had with the old ZTS version and also made it
more stable. Stability improvement was not only due toTLS but also to
the great work Anatol pushed into this RFC by reviewing the entire php
code base and extensions (incl pecl). ZTS mode became quite solid.
From a performance point of view, it matched or beat NTS on Windows,
and in some cases by good margin. I do not have the numbers at hand
but if someone is interested, looking at the discussions for this RFC
should give them all the details.

All this applied to ISAPI as well for the time it was still part of
the core, only even less stable.

Now, about ZTS usage on Windows being huge. This is correct. Is it a
de-facto choice for Windows users? No. It is a communication and
marketing issue. Microsoft introduce FCGI support to IIS long time ago
and became a de facto standard for any kind of PHP (or other) support
with IIS. Application pool and most of the IIS support are fully
supported with PHP and FCGI.

Many developers use ZTS with Apache thinking it will be better and
faster, or comparable to FPM, because FPM is not supported on
Windows.This is clearly something we need to communicate better.
Keeping in mind that FPM (and its key features) are not possible to be
ported to Windows due to the windows architecture. However, many
webservers support similar features (IIS or other) natively and with
php-FastCGI.

From a strategy point of view, I  agree with Zeev. With a slightly
different approach.

We need thread safety internally for many modern needs (async
processing/IOs f.e. use threads internally). From an end user
perspective, that should be transparent (easier said than done). That
being threading in userland is complete different story. There are a
few great things out there to make this case:

- Joe made a great job with his parallel extension
(https://github.com/krakjoe/parallel).
- AMP has something similar (from a user perespective) with
https://github.com/amphp/parallel.
- Swoole, Zeev mentioned it and I highly recommend to look at it
- many other projects trying to change the way we use PHP, ReactPHP f.e.

You get the idea. There is a need. And I think we should provide the
tool to help them to do it nicely and with good performance. ZTS is
not going to help here, this is not adapted to where we have to go (or
should be already). I would rather scratch it and discuss with Swoole,
Joe, AMP or React teams, get inspirations in other languages to see
what can be done at the engine level to make this kind of tasks
possible, portable and fast.

Best,

On Fri, Feb 15, 2019 at 5:33 AM Zeev Suraski <zeev@php.net> wrote:
>
> On Thu, Feb 14, 2019 at 7:57 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
>
> > Data point: At Platform.sh (web host), we've been running ZTS builds of
> > 7.1,
> > 7.2, and 7.3 exclusively for a while now.  We don't even offer non-ZTS
> > versions of those releases.
>
>
> I presume you haven't been using a threaded Web server module though, right?
> As I pointed out in my lengthy response to Levi, it's thread-safe Web
> server plugins that are bad news, not ZTS itself.
>
> It's been quite solid
>
>
> It would be solid as long as you don't use a thread-safe Web server
> plugin.  Then, any slight thread-safety issue in any of the underlying
> libraries could result in your Web server process crashing in its entirety.
>
>
> > , and mysteriously even
> > slightly faster than the non-ZTS version of 7.1 on code that wasn't doing
> > anything threaded at all (which surprised me, but hey).
> >
>
> That is indeed curious.  I'd be interested to follow up with you to better
> understand how you measured it, as it goes against both my expectations
> (ZTS code does more compared to non-ZTS code) and my experience.  We can
> maybe take that offline...
>
>
> > I have to agree with Joe's post yesterday on this front:
> >
> > https://blog.krakjoe.ninja/2019/02/parallel-php-next-chapter.html
> >
> > It's not threads that are unsafe for end users; it's badly designed thread
> > APIs that start by pointing a gun at your foot. :-)  A well-designed
> > thread-
> > backed concurrency model (Go routines being a good but not the only
> > example)
> > is way better, and at least from a user side I frankly prefer it to async
> > IO.
> > You get much of the same benefits with less need to restructure you're
> > code,
> > even with async/await.  Plus you can parallelize CPU intensive tasks,
> > something async IO simply cannot do.
> >
>
> It's not just a matter of preference.  Async IO is significantly more
> efficient than threads both in terms of speed and memory overhead.  It's no
> coincidence that all high performance Web servers nowadays are async-IO
> based, and that the most scalable app delivery platforms are also async IO
> based.  In addition to the underlying building blocks being more efficient,
> the async-IO model, where you have a long running process that is in fact
> directly responding to HTTP requests - is most likely in itself bringing
> the biggest performance gains - as effectively you have a 'hot', ready to
> execute app that can preload all sorts of elements into memory and be ready
> to go with little to no initialization (a direction we went in with the
> code preloading feature, but things like Node.js or Swoole go a lot farther
> than that).  All that doesn't come to say we must not implement threads -
> not at all - just that they're probably not the preferred method of
> achieving in-request parallelism within the Web environment.
>
> Zeev



--
Pierre

@pierrejoye | http://www.libgd.org