Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104427
To: internals@lists.php.net
Date: Thu, 14 Feb 2019 19:27:41 -0600
Message-ID: <4909380.d2NT4XQ1VY@vulcan>
In-Reply-To: <CAJHtznxu41gQTKRTGOC4iEP_5nJXbMAfKNTN6APcegA74rfa8A@mail.gmail.com>
References: <BYAPR02MB5766B8D8FCE674BF544B7FB0BF660@BYAPR02MB5766.namprd02.prod.outlook.com> <1882693.l3SFSfi3S3@vulcan> <CAJHtznxu41gQTKRTGOC4iEP_5nJXbMAfKNTN6APcegA74rfa8A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart31007584.hf5EKm2Sc6"; micalg="pgp-sha512"; protocol="application/pgp-signature"
Subject: Re: [PHP-DEV] Re: ZTS improvement idea
From: larry@garfieldtech.com (Larry Garfield)

--nextPart31007584.hf5EKm2Sc6
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"

On Thursday, February 14, 2019 4:33:27 PM CST Zeev Suraski 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.

Right, we're using typical Nginx/FPM for web requests.  ZTS is just there so 
that CLI users can run their own process that use pthreads.  (I don't know if 
anyone has done so, but we support it, so yay.)

> > , 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...

It's been a while since we ran the tests.  I believe it was just for the 7.1 
release, and we tested with normal ab or something.  Happy to chat off-list if 
you want but I'm not sure that I can remember much at this point. :-)

> > 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

I'm not saying async IO doesn't have advantages, and having a "hot" running 
application that persists between requests is something I really want, too.  
However, async IO by definition doesn't help unless your blocker is IO.  Often 
it is, but often you have a CPU bound problem.  Even in PHP.  (I used to work 
on Drupal, remember; it does a LOT of non-IO work...)  Async IO isn't going to 
help you much if IO isn't your bottleneck.

I think we're largely on the same page, though: Threads good, threaded 
webserver host bad.  PHP should have good thread support in the future.  
Whether ZTS specifically counts as "good thread support" at the engine level I 
have no opinion, as I haven't been anywhere close to the engine to know what 
I'm talking about.

--Larry Garfield
--nextPart31007584.hf5EKm2Sc6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit

-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEE/ph/GXfY8v0YwFBp4MMKwDFxYXcFAlxmFY0ACgkQ4MMKwDFx
YXekdwgA7P0iVlSb4eiikcMfWSSbQtkeeANL3d8QvEEK90C5qm2gFQBSElUWnjhr
+K7u18/MvOaJzEH9D4Mt5JKRIO9R5mHzHgHJoFjOgBIjOs+DGEfHUzIYBHO/6JFa
UAKNE6nJZn7VAIfpbVktW37ZaeQjIkJa4t61VufWaEbU4/Ok/pxAGfBSPgFmIRh1
jO8gzejVAnX2XjXZsNCpgpV8yLQBqhzMD2hevuuO0W5Soif1kCMewlx4OIp4X5R4
BPiUoOCfCl+r2RCBJL8x/WNra0IaID3oyIOCOCp46UPh5uWbS54qz+oE+W3z0WIH
iJ8pFt/M10Kn4lwQ6JAWzzdyX+bTbw==
=B1tK
-----END PGP SIGNATURE-----

--nextPart31007584.hf5EKm2Sc6--