On Tue, 2013-01-29 at 14:18 +0100, Pierre Joye wrote: > > > 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 :). > I myself wouldn't use current-PHP for shared hosting in ZTS mode. Stack overflows (functrion nesting, pcre, ...) will kill the whole process so one bad guy can hurt other parallel requests for other vhosts quite easily. With a multi-process-setup such bad user can hurt performance but not completely kill other requests.
That aside: I agree that a system written for threaded environments can benefit from threads vs. processes (not only memory access, but also context switches etc.) at least on some operating systems. But PHP (currently) is not that kind of a system. (I went through this quite a bit with Solaris devs in the past, which led to some improvements which were available via http://hg.genunix.org/php-experiment.hg/ which seems to be down ...) My primary perspective is that I claim that barely anybody is doing more than compile-testing in ZTS mode. TSRM macros are also often one of the biggest causes of confusion when teaching extension writing/patching of PHP, even though for 95% of the cases it can be seen as a pure blackbox. I for one would vote for a simplification of the codebase over a small performance win. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
