Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104425
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
	s=turbo-smtp; d=php.net;
	h=Received:Received:X-TurboSMTP-Tracking:X-Gm-Message-State:X-Google-Smtp-Source:X-Received:MIME-Version:References:In-Reply-To:From:Date:X-Gmail-Original-Message-Id:Message-ID:Subject:To:Cc:Content-Type;
	b=AuU8xbqtDsTG9DjkkQaGCTqlFRAmDjpFnMmdLkkGQe0x+OLYEMmv6l1KbLJBJE
	ZCYMxZExG+5tEfomDTNi938pvf8Ty6oIdMrno3/Ldv8A6AYttbvRtb2yJN7eNYON
	GkwXLzZHZM+Kv0/CqSL29hKSGYjGcvp4AubgvM3FWa1xU=;
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>
In-Reply-To: <1882693.l3SFSfi3S3@vulcan>
Date: Fri, 15 Feb 2019 00:33:27 +0200
Message-ID: <CAJHtznxu41gQTKRTGOC4iEP_5nJXbMAfKNTN6APcegA74rfa8A@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e746010581e23f14"
Subject: Re: [PHP-DEV] Re: ZTS improvement idea
From: zeev@php.net (Zeev Suraski)

--000000000000e746010581e23f14
Content-Type: text/plain; charset="UTF-8"

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

--000000000000e746010581e23f14--