>> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
