On Thu, Feb 14, 2019 at 7:57 PM Larry Garfield <la...@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
