Re: ZTS - why are you using it?

On Tue, Jan 29, 2013 at 1:15 PM, Pierre Joye <pierre.php@gmail.com> wrote: > > > On Jan 29, 2013 12:10 PM, "Zeev Suraski" <zeev@zend.com> wrote: > > > > > The other main reason from my side to keep ZTS is Windows. Windows > > cannot > > > perform well using process based SAPI. > > > > Windows actually works quite well with FastCGI. So well Microsoft even > > created their own version for IIS. It's outperforming the ISAPI module by > > a wide margin. > > Laziness and design mistake. Everything on windows (AD,IIS, asp.net, etc) uses thread. > > And no, nuts is not faster. I am not talking about PHP zts, but in general. Of course everything that is Windows native uses threads, but I don't believe any language that is single-threaded on other platforms - has a thread safe version for Windows. I disagree that laziness and design mistakes are what makes ZTS slower. It's slower by design, since instead of relying on operating system isolation - you have to emulate it yourself in userland code. Contrary to popular belief FastCGI actually works very very well on Windows, and has substantial advantages over using a server module - even on Linux (it's no coincidence that there are hoards of users migrating from Apache to nginx, where a server module isn't even an option - and they're seeing better performance, not worse). > > > Other than Apache/Windows not having FastCGI support(*), I really can't > > imagine any situation where using ZTS inside of a Web Server context makes > > any sense at all. I wouldn't call it a new trend, it's both old (I've > > been pushing for it since at least 2006, probably earlier) and with very > > solid technical reasons (faster, more reliable). > > Miss the rest of my mail or? Current implementation is outdated and slow. How does it relate to what I said? Regardless, a new implementation of ZTS will not change the fundamentals. We're unlikely to ever achieve single-threaded performance or reach the same level of stability with ZTS. With a system like PHP that is all about concurrency of stateless, independent requests - I don't think we're going to reach any meaningful limits any time soon. FastCGI has another huge advantage, in that it breaks the 1:1 linkage between a 'processing unit' (a web server process or thread) and a PHP instance, and makes it an n:m mapping - in that you could have a lot more web server processing units than you would need PHP instances. That's one of the key reasons you can achieve better performance / density with PHP on nginx than you can with Apache. The same would apply to IIS - ISAPI vs. FastCGI. Zeev