Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:74074 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30473 invoked from network); 8 May 2014 22:45:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 May 2014 22:45:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=rasmus@lerdorf.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=rasmus@lerdorf.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.216.52 cause and error) X-PHP-List-Original-Sender: rasmus@lerdorf.com X-Host-Fingerprint: 209.85.216.52 mail-qa0-f52.google.com Received: from [209.85.216.52] ([209.85.216.52:50597] helo=mail-qa0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 81/E7-15882-EE80C635 for ; Thu, 08 May 2014 18:45:04 -0400 Received: by mail-qa0-f52.google.com with SMTP id cm18so3277971qab.39 for ; Thu, 08 May 2014 15:45:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=XNv5qKv0uUGDz6cE62Pu0NraP1nSHuKBLJSrUm4uDLU=; b=H3WI+emV44zG7ScIR3Ce/bQKYL275lNGZq90L1rZUepXUjXculjtAB/ybgxAULtRXS 3yOCw1GcG9jWPPiy6EglTn96phzM7bBMCP6IqqSH/mN7h4CLLfhksLjQMsCthNEohkFl FYpAeapxxXf8wK9Fbj2LACZu/+oCK7uGuEqYyVL0oq/GorQ02NhHL4PgIZlhunHXt3Y2 G1ep+bWbE/y7wFCFe4grNXAzoLPTE7fTgf1EohEOETjSQaZ7toBMPCxun7ukptcClFBt GCjP36oAJATCB8lUsDEMsAsQ7RB2aEMU+xRfHQBIlM7qQZTbls4wWdPCLgjcGRWYK6Jo PDJw== X-Gm-Message-State: ALoCoQnZPI6FrwarjTLJ7dzb6fxIFksL3ucOY3BeXjnbCKntEgz+KtlRZk4PmluFZcQri74kLKCH X-Received: by 10.224.97.69 with SMTP id k5mr9574914qan.8.1399589100169; Thu, 08 May 2014 15:45:00 -0700 (PDT) Received: from [192.168.200.30] (c-50-131-44-225.hsd1.ca.comcast.net. [50.131.44.225]) by mx.google.com with ESMTPSA id p2sm3540942qah.38.2014.05.08.15.44.58 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 May 2014 15:44:59 -0700 (PDT) Message-ID: <536C08E9.6090902@lerdorf.com> Date: Thu, 08 May 2014 15:44:57 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Zeev Suraski , Andrea Faulds CC: Andi Gutmans , Sebastian Bergmann , internals@lists.php.net References:

<5369CED9.5010001@php.net> <4339111475046055305@unknownmsgid> <578A5A21-A820-42AD-A218-FB8049F63B82@zend.com> <3A72C770-9A9F-40C9-9DFE-F40478709BA8@ajf.me> <311084565853739035@unknownmsgid> <536BA9FE.1090408@lerdorf.com> <2c470224f5eca827363a3c5878bc709d@mail.gmail.com> In-Reply-To: <2c470224f5eca827363a3c5878bc709d@mail.gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="COIHpXnLmNsdcVuMlnMfV0RxGVPQcaBNG" Subject: Re: [PHP-DEV] phpng: Refactored PHP Engine with Big Performance Improvement From: rasmus@lerdorf.com (Rasmus Lerdorf) --COIHpXnLmNsdcVuMlnMfV0RxGVPQcaBNG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 5/8/14, 2:24 PM, Zeev Suraski wrote: > 1. You're right it buys operational stability; But then, people who'll= go > on a major PHP version upgrade will expect some level of operational > instability (we should hope so at least, because they'll probably get i= t). > App breakages are an order of magnitude (or two or three) more painful = than > relatively simple changes to monitoring tools or administrative scripts= =2E We tend to provide very good forward compatibility with E_DEPRECATED warnings and a detailed UPGRADING document. This means you can prepare a codebase for the next major release well ahead of time and run it in production on the previous version while it is easy for the developers to run a newer PHP version on a dev vm to make sure everything gets caught. At the point of the upgrade it becomes quite painless. That is, the work is nicely spread out and there is no jarring company-wide disruption since all app breakages have been pre-fixed. When swapping out an infrastructure element like the web server or at least an architectural aspect of the web server, it is something that touches a lot of moving parts and hits not just the dev team but also the test and ops teams quite hard. It is hard to prepare for because you don't really know if you missed something until you swap out the production implementation that is running at scale. So the angst involved is much higher. > 2. I never argued that FastCGI/fpm is faster than mod_php; It's proba= bly > not (it's roughly as quick from my experience). But it's *a lot* more > scalable (in terms of in-machine scalability), since it breaks the 1:1 > mapping between Apache processes and PHP processes. Often, for a typic= al > setup of with hundreds of Apache children, you could use just several d= ozen > PHP processes when using FastCGI. With mod_php, after a short while yo= u'd > have each Apache process consume a dozen or more megabytes of memory - = times > hundreds of processes that's a lot of memory; With FastCGI, you'll onl= y > have several dozen processes consuming that much memory, while the Apac= he > processes can stay lean. Not to mention you get to use more efficient= > mpm's, ones mod_php doesn't support - and save even more memory. With > requests growing shorter, simpler while also rapidly growing in frequen= cy - > this sort of density is very important IMHO. Yup, I don't disagree that it is a more efficient model, especially for smaller shops that don't have the luxury of using CDNs and having multiple server pools for different purposes. However, for larger sites, every request that makes it through to the Apache+mod_php process tends to be an actual heavy PHP request. Static files aren't handled by that pool of servers. In that scenario the server density differences between FastCGI and mod_php becomes much smaller. If every request is heavy you are going to need the same number of each. You gain a bit by not having the Apache piece in each PHP process, but it isn't all that significant and when weighed against the operational cost of switching it doesn't seem all that attractive. I would love to be able to convince sites like that to switch, but I haven't been able to come up with enough technical benefits to outweigh the operational costs yet. -Rasmus --COIHpXnLmNsdcVuMlnMfV0RxGVPQcaBNG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iEYEARECAAYFAlNsCOkACgkQlxayKTuqOuA0YQCfdog8e+LU3lv03PFcMfqGSMw4 wrwAn2X5JvSGJa3F7zWma7OAv1WS3TgO =m25I -----END PGP SIGNATURE----- --COIHpXnLmNsdcVuMlnMfV0RxGVPQcaBNG--