Hacker News new | ask | show | jobs
by creshal 3783 days ago
> If a web worker is waiting for another service it should release the CPU until the service responds.

Emphasis on "should". With your average drivel (Wordpress e.g.) this doesn't happen and the load on the application server scales nicely with the response time of the database server. 10 requests waiting on a locked table for 2 seconds = load of 10.

2 comments

Are you saying that the PHP mysql driver waits for the results with a busy loop? I have to say I find that hard to believe.
> I have to say I find that hard to believe.

¯\_(ツ)_/¯

Steps to reproduce: Set up one mysql server. Set up one PHP application server (nginx+PHP fpm in my case, shouldn't make a difference with mod_php) on a different machine. Configure Wordpress to use said mysql server. Lock the database in some way (say, mysqldump of a Wordpress installation with millions of records in wp_options), then hit the application server with regular traffic (or ab), watch as load reaches pm.max_children. On the application server, not the database server.

If a service waits for another service, then that other service often contributes to CPU load.

Not always, no...

Not when the other service is on another machine, like in the case I described.
Sorry, I was sloppy. I meant that it generates CPU load somewhere (or I/O load, for those OSes where those two are cleanly separated).

If you measure the CPU load on half the CPUs that are involved in serving a user, you're not really measuring anything. Ditto if you're outsourcing (parts of) the backend and not measuring the outsourced service level.

> Sorry, I was sloppy. I meant that it generates CPU load somewhere (or I/O load, for those OSes where those two are cleanly separated).

Not necessarily. In the scenario I outlined to icebraining, "load" is generated (on the app server) by simple busy waits due to lock congestion: Full table locks by mysqldump block the database server to clients, so the database server itself is seeing negligible load (it's only serving one client after all).

> If you measure the CPU load on half the CPUs that are involved in serving a user, you're not really measuring anything

I'd rather argue that the Unix/Linux CPU load metric is meaningless either way, except in a vague "something's wrong somewhere, probably" way.

IMO if there's enough busywaiting that it shows up on the CPU load, then there's so much busywaiting that that is a problem, because a CPU that's busy with such chores is not available for real work. The CPU load is not (as you say) very lucid, a bit like the question mark in the "unix car" joke, but in that particular case it's caused by a real problem: Too much busywaiting.