build: Set PHP_CLI_SERVER_WORKERS=8 in composer serve
- This way page views and most common user interacts don't involve queued requests by default.
- Devtools waterfall charts show realistic latency numbers, instead of making it seem that serving a .jpg is slower than a PHP request, because it happens to be queued behind one, when there are only 3 requests at the same time.
- Profilers become more comparable between quickstart, docker, vagrant, beta, and production.
- Allow benchmarking with 'ab' out of the box, with at least some concurrency, and in a way that the concurrency is obvious and easy to find (the user ran 'composer serve' and can see WORKERS= setting in the CLI output, as well as in composer.json).
- Slightly faster page views, especially interactions like loading VisualEditor where there are 2-3 concurrent API requests.
Why 8
I believe most CPUs used by contributer's devices have at least 8 cores
these days. However, even if they have a 2-core or 4-core machine,
I'd much rather requests be handled concurrently by the OS, than
forcefully queued in their entirety.
Most latency in web apps tends to be blocked on I/O (file, network,
database), so there's plenty of oppertunity for CPU sharing. Even in
WMF production, we spawn 2x the php-fpm threads as we have CPUs
(fpm_workers_multiplier).
We could comfortably set this to 16 or 32 as well, but given this is
a local server for a single-user, you're realistically not going to
actually be able to (naturally) cause more concurrency, short of
benchmarking. 8 seems about right as being just above what is normal
on a typical pageview, yet short of potential arguments about how
much and whether to induce CPU sharing for most people.
Bug: T347347
Change-Id: I7d6fbe02e13375d4e95c12165c29469cd0946d34