On Tue, Jan 29, 2013 at 1:52 PM, Zeev Suraski <z...@zend.com> wrote: >> -----Original Message----- >> From: Pierre Joye [mailto:pierre....@gmail.com] >> Sent: Tuesday, January 29, 2013 2:19 PM >> To: Zeev Suraski >> Cc: Johannes Schlüter; PHP internals >> Subject: Re: [PHP-DEV] ZTS - why are you using it? >> >> On Tue, Jan 29, 2013 at 1:06 PM, Zeev Suraski <z...@zend.com> wrote: >> >> >> It is inter process sharing and is very expensive, nothing to compare >> > with shared >> >> memory within a single process, accross many threads. >> > >> > What are you basing that assertion on? Shared memory should have >> > identical performance to regular process memory. It's mapped in very >> > similar way. >> >> Testing maybe? > > Retest then, you've got it wrong. Shared memory (or memory mapped files > as they'd be on Windows) are simply memory, it's available to the process > in exactly the same way and while the OS does slightly different > book-keeping for it in how it populates the pages - it's negligible.
It is not negligible, also the locking is different. Also, if I remember correctly there is no rwlock support either, which is a huge cons. >> No, we can't. The main reason of the bugs and performance issue is due > to the >> current implementation and how extensions developers have to deal with > it. It is >> not separable from discussing what could be the worst decision we ever > made, >> droping thread safety. > > Well, I'm not interested in discussing the implementation when the need > isn't clear to me. > For example, you could say that thread-safe PHP would be 2x faster. Or 2x > more memory efficient. Or will enable us to do XYZ which we otherwise > can't. There are quite a few things I can do on Windows only in thread safe environments (f.e. ESENT, builtin DB, used by AD for example, damned fast). > For now, an *utopian* ZTS mode would, at best, not give us anything. > Even if we put aside the performance/reliability issues - why would > someone want that mode over other modes? I must be really unclear or something along this line. Alone on IIS, there are dozen of features you can't do nor use using fastcgi. Apache could also be used in a better way (windows here too, linux has a module for both builds of apache). btw, have you tried to compare IIS/FastCGI (I won't even try with apache+fastcgi) on Windows vs nginx-fpm on linux? I would be very surprised if your numbers show that they are equivalent. > Pierre, I'm sorry, but when you state something like '[shared memory] is > inter process sharing and is very expensive', there's no other way to > describe it other than a myth. Better theoretical performance is a > misconception. The best PHP performance/density available today is on > nginx, which couldn't be farther away from > multithreaded-PHP-in-process-arch. > > Even after what you just said, you've yet to bring up a single reason for > why one would want to use ZTS inside a web server context. You seem to > love ZTS with a vengeance but you can't quite explain why. My 'company' > didn't decide anything regarding ZTS. It was me, probably the person with > the most experience with ZTS back in the day, and it was probably much > more difficult for me than anybody else to realize that the ZTS approach > was the wrong path to go to as it was my baby project. It could have been the wrong path for some situation back then, but it is definitively not wrong to improve thread safety. I would rather have one single build instead, and enable the ts related stuff when necessary. It will add some more functions in the engine but it would be much more clear and easier than what we have now. > BTW, for the love of [insert here], I'm not talking about killing thread > safety. That's how it looks and that's where this discussion is going, tbh. > It's useful for long running processes, and who knows, maybe in > the future we'll have threads inside PHP. But I *am* talking about > telling people that using ZTS in production is not recommended and that > they should be using FastCGI instead. As far as I remember, we already do that for a couple of web servers. And in the long run, I will rather tell not to use FastCGI for dedicated hosting and the likes. That being said, I also met many ISPs which are not happy with the all-fastcgi, memory usageand performance were the issues (have to read my backlog for other details :). Cheers, -- Pierre @pierrejoye -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
