Hacker News Reader

Comment by arantius | Hacker News Reader

> I’ve heard the argument "you don’t need a compiler, since PHP is rarely the bottleneck" for many years. I think its complete bollox. ...

> Unless your PHP server is sitting there idling (which is probably the case for many PHP servers out there) ...

Don't these two statements (abbreviated in my quote above, but directly one after the other as quoted) directly contradict each other? My personal experience is also that the CPU is never the bottleneck in (well written) PHP apps. You're usually always waiting for the DB or the network/io latency of something else like memcache.

In fact, I know at my last job (handling ~100s of millions of dynamic PHP requests/day) that PHP's gzip compression was turned on specifically because we had gobs of spare CPU, so using it to save bandwidth was a win both for speed and for the bill.

View on HN

Here we go again.

If you have lots of spare CPU on machines in a web server farm, you have too many machines. Even though I/O is the bottleneck for any single request's response time, CPU is generally the bottleneck on total load.

that's a double edged sword though. if you don't have enough spare cpu, you won't be able to handle any sort of spike in usage. say from an advertising campaign that works a little too well or if a server goes down.

and once you start maxing out boxes, the load comes even harder since the site loads slower. you very quickly run out of resources and suddenly you're SOL and everybody's mad that the site won't load.

honestly, it's hard to point at any one source of problems when scaling a site. cpu, ram, and i/o are all equally problematic. and if you under plan any one of those it can take your site down into a spiral of doom.

you really must allocate your resources for peak load, not for average or nominal load. and then allow for some failures.

Sure. But under max load, that gzip will be adding to your problems.

And of course, graceful failure is an art in itself. You have to start turning down requests before you actually hit peak capacity, or you risk getting stuck in a thrashing pit.

Actually, in that same situation, I believe it was limited by memory (MB per apache+php process), and number of processes available driven by latency. Given the number of processes running on a machine, and the memory that each consumed, we "couldn't use up" the processor capacity, the memory ran out first.

Maybe we could have switched to something lighter, but the cost of all that development and testing would outweigh a handful of extra machines.

I am NOT very informed about server tweaking, so please add a pinch of salt as appropriate... But aren't there two related issues to consider? Assuming a simplistic two-tier architecture consisting of a UI/domain logic server (in PHP) backed by a database, the first question is whether the speed of the PHP bit affects the total load the server can handle. Presumably if it is idling waiting for the database, you could handle some more connections and need to work on optimizing your database until you reach a sort of equilibrium where both are maxed out.

The second issue is latency. Even if it spends time waiting for the database, the amount of time processing each request affects the amount of time a client waits for a response. Even if the database is the limiting factor on the number of simultaneous requests that can be handled, you may still want to increase the speed of handling each request to make the UI snappier.

Am I whistling in the dark here?

No. And even when you have lots and lots of concurrent I/Os going in a blocking server design, CPU becomes a different kind of constraint: it governs how fast the kernel can context switch.

I don't see the contradiction...

Reply on news.ycombinator.com