Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:66373
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.219.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAAyV7nF=nOGzG+Y1nv8sL8g34p4iVJrdd31GT8UHM3MnD9VViQ@mail.gmail.com>
References: <435a322ccb14090d3bcf6bf8a110396d@mail.gmail.com>
	<CAF+90c-FeWE960EJsvpdNu+CpCOyK84=mTyfH_vgUzPRSmD7gA@mail.gmail.com>
	<3206872690693024300@unknownmsgid>
	<CAAyV7nH9jafLksLG105sySTzVZmWCFJ6D-4nE6CFAxU1rF9kpg@mail.gmail.com>
	<512FBDCD.3030507@lerdorf.com>
	<CAA9esyS48hze6_39bu_P22TP=mtVm-wzTKKRrpABwmhv99=ohg@mail.gmail.com>
	<CAFMT4NqHwSHwpN6NZHK2fQPjTFSdCZqYX5=f5cqk0DBrLXkUTw@mail.gmail.com>
	<CAA9esyS-Eu2=s66r8YC1nmE0TtOSOW0xv_MebpaV-YYKm4y2uA@mail.gmail.com>
	<CAAyV7nF=nOGzG+Y1nv8sL8g34p4iVJrdd31GT8UHM3MnD9VViQ@mail.gmail.com>
Date: Thu, 28 Feb 2013 14:51:24 -0700
Message-ID: <CAFMT4NoZfFxFgnNu34ZFvNCpN_kakfWPdmXqFj0_YVKriZSqHw@mail.gmail.com>
To: Anthony Ferrara <ircmaxell@gmail.com>
Cc: Florin Razvan Patan <florinpatan@gmail.com>, Rasmus Lerdorf <rasmus@lerdorf.com>, 
	Zeev Suraski <zeev@zend.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [PHP-DEV] [VOTE] Integrating Zend Optimizer+ into the PHP distribution
From: morrison.levi@gmail.com (Levi Morrison)

>> Would you run PHP against 10k+ req/s in production without opcode caching?
>> On how many machines without / with?

This is getting a bit off-topic now, but all my work is geared towards
tools for users and system administrators in the LAN. We don't need an
op-code cache. We never get more than six unique users per day with
fairly low traffic from each. Does that mean we aren't important? I
sure hope not. . .

For us the new features are more helpful (we have plans for generators
already) because it makes certain iterators easier to build and
maintain.

> I'm not sure about your stack, but every stack I've seen at that high of a
> load is built very custom for the problem at hand. And it isn't typically
> upgraded across minor versions (in fact, it's typically only upgraded for
> security). At least that's my experience everywhere I've seen that big of a
> farm... And when it is upgraded, it's usually a very coordinated effort that
> takes a LOT of planning and has a lot of moving parts...
>
> And to be fair, how many installs are there that get 10k req/s? A few
> hundred? That's not the kind of system we should be targeting when
> discussing a language feature/change. Sure it's sexy, but it represents less
> than 1% of the install base of PHP (much less, prob on the order of 0.01%).
> So while I wouldn't write them off (far from it), justifying a change
> because it matters to that scale is like justifying ejection seats in cars
> because hitting a wall at 200mph on a race track can kill you...

Completely agreed. How many millions of tiny sites use PHP compared to
the few that serve up that kind of traffic?

I'm not saying performance isn't a concern; I am saying that your
concern is not typical of the average PHP developer.