Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:65341 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90535 invoked from network); 29 Jan 2013 09:56:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jan 2013 09:56:20 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.178 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.217.178 mail-lb0-f178.google.com Received: from [209.85.217.178] ([209.85.217.178:61013] helo=mail-lb0-f178.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5A/93-07604-3CC97015 for ; Tue, 29 Jan 2013 04:56:20 -0500 Received: by mail-lb0-f178.google.com with SMTP id n1so463544lba.23 for ; Tue, 29 Jan 2013 01:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=9OmfKmwWH9ZHbgKkBqBhkObsIaK09vYp4s9FzRIxJns=; b=jiwY1co5TqsTO57rHdcIs8eDKcXnXqVld0n0vcfX+TOgea+heJ4VDpYrpBLsluwiJP /526rGuL0b4/L4S8IQwT8WB3nylpSyME9/UekOkXExMD5Ay3VbSdn+sFUrrD6kFvlmvL vUAFtGetwTKDlYdf4glYg+RR7zZ3v5pjK0/Tszt7/2zKdgWgVSY3vIubWH4g7omXxN8+ ShT0DwIvVkLmJcxCsok9FKDAAxxd5Li/VI/1+2L85TePzPIO9Giv5fdcYMp5bx6+HhDo ymz/98LDtinTt3bB662/UpRi7lcztKemmKYWuYkHcD/Qo0tYupftUPi4r2Cubfsqpl5f bM0g== MIME-Version: 1.0 X-Received: by 10.112.103.167 with SMTP id fx7mr244677lbb.19.1359453376172; Tue, 29 Jan 2013 01:56:16 -0800 (PST) Received: by 10.112.2.69 with HTTP; Tue, 29 Jan 2013 01:56:16 -0800 (PST) In-Reply-To: References: Date: Tue, 29 Jan 2013 10:56:16 +0100 Message-ID: To: Zeev Suraski Cc: PHP internals Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [PHP-DEV] ZTS - why are you using it? From: pierre.php@gmail.com (Pierre Joye) hi Zeev, On Tue, Jan 29, 2013 at 10:03 AM, Zeev Suraski wrote: > Which brings me to the subject of this mail =96 why are you using ZTS PHP > instead of single threaded PHP? The reasons not to use it are few but > fairly major =96 it=92s significantly slower than the non-ZTS PHP, and it= =92s > significantly less robust in the sense that a single bug somewhere can > bring down an entire server (or at least a bunch of many different > threads). What are your reasons to choose it over FastCGI? There are situations where FPM/FCGI are not appropriate, or the server used does not support NTS (Apache windows for example, when fcgi is not an option). However, in the long run, I would like to kill TSRM altogether, moving the file/IO related parts where they should be implemented, either the engine or main. Does it mean we will kill thread safety by doing so? No. My idea is to replace it with LTS (thread local storage) which drastically reduce the thread safety issues due to its exact nature, store local thread data per thread and not per process. Issues include well know crashes due to non thread safe code (almost none left in core, but some libs have issues) and brings a huge performance improvement. The other main reason from my side to keep ZTS is Windows. Windows cannot perform well using process based SAPI. It won't match linux as long as it runs within a webserver using a process based implementation (but CLI does not match linux performance and is even faster in a couple of use cases). I've made some tests to write new ISAPIs for IIS8 and with the httpkernel (1). The performance are very promising, given that it is still only a proof of concepts. Having an ISAPI also allows a tighter integration to IIS8 (pipelines, auths, scripting, etc.), which is not possible to do now using fastcgi (no direct access but using RMI or the IIS shell, but horrible, in all possible ways). Conclusion: Yes, TSRM is horrible and does not match modern thread safe implementation (APC does it better for its usage f.e. using rwlock). However it would be a very bad idea to give up on thread safety only because the relatively new trend is all about single threaded/process based implementation. These systems have limits and I'm sure we will see some big change in this area in the couple of years. TLS will let us to do the transition and we can 'easily' support extension developers to port their extensions. (1) similar to our builtin webserver except that it can be used in production servers. It is what IIS used under the hood. Having a SAPI relying directly on HttpKernel will allow one to create many app pools using PHP only. It will work smoothly even if IIS runs on the same host, sharing the same IPs or ports, even the cache will work. Cheers. -- Pierre @pierrejoye