Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65398 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 80932 invoked from network); 29 Jan 2013 14:27:09 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jan 2013 14:27:09 -0000 Authentication-Results: pb1.pair.com smtp.mail=johannes@schlueters.de; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=johannes@schlueters.de; sender-id=unknown Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error) X-PHP-List-Original-Sender: johannes@schlueters.de X-Host-Fingerprint: 217.114.211.66 config.schlueters.de Received: from [217.114.211.66] ([217.114.211.66:61222] helo=config.schlueters.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 47/2F-10721-83CD7015 for ; Tue, 29 Jan 2013 09:27:04 -0500 Received: from [192.168.2.20] (ppp-93-104-29-211.dynamic.mnet-online.de [93.104.29.211]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by config.schlueters.de (Postfix) with ESMTPSA id 222226545C; Tue, 29 Jan 2013 15:27:01 +0100 (CET) To: Pierre Joye Cc: Zeev Suraski , PHP internals In-Reply-To: References: <1359459921.3916.105.camel@guybrush> Content-Type: text/plain; charset="UTF-8" Date: Tue, 29 Jan 2013 15:27:58 +0100 Message-ID: <1359469678.3916.451.camel@guybrush> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] ZTS - why are you using it? From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=) 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