see also https://bugs.php.net/bug.php?id=74971 - the "HY000/2002): Resource temporarily unavailable" needs to go away because the machine itself is far away from overload when it respons within 0.003 seconds on additional requests from the browser due benchmarks are running

For the original issue (about back_log value): it is not completely ignored, but the actual rules for its setting are indeed far from what the KB says. I'm not even sure it's a documentation issue only, possibly it needs to be fixed on the server side as well.

Apparently the current rules for back_log are such:

• if back_log is not provided, or it's provided and its value is greater than max_connections, then the given value is ignored and it's auto-sized instead, as
  min((50 + max_connections/5),900)
• otherwise the provided value is used.

I'll leave it to serg to decide if it's supposed to be this way, and also what to do with the issue in the comment.

frankly when i set a value i mean that value without any "but" or "if" - there is no point to autosize something any longer - you can warn in the error log for whatever reason and if i find out that the value has the desired result of running a benchmark on a 6 years old machine wihtout database connecetion errors i will write another bugreport - but leave my config values in peace or at least mention in the errorlog that you don't care about them instead make the databaseserver like a gambling machine

I don't think it was supposed to be quite that way. I'll do this:

• If back_log is not specified at all, or auto-sizing is requested (with --back-log=0 or with --autoset-back-log), then the value will be min((50 + max_connections/5),900)
• If back_log value is specified to be larger than max_connections, it's clipped to be equal to max_connections

I think this was the original intent.

"If back_log value is specified to be larger than max_connections, it's clipped to be equal to max_connections" is at least better than the current behavior but in reality a so called "backlog" is used to keep new connections in a queue instead let the client fail hard and this makes a lot of sense because it helps due load-spikes keep the active threads as low as configured, don't fail every new connection immediately but let them suceed as soon as a previous connection closed and no timeouts exceeded

I agree. Removed "larger than max_connections" logic altogether.

looks way better with 10.2.8 - no single "HY000/2002): Resource temporarily unavailable" message in the application errorlog

Concurrency Level: 150
Time taken for tests: 214.193 seconds
Complete requests: 1000000
Failed requests: 0
Keep-Alive requests: 1000000
Total transferred: 4188197222 bytes
HTML transferred: 3777430423 bytes
Requests per second: 4668.69 /sec (mean)
Time per request: 32.129 [ms] (mean)
Time per request: 0.214 [ms] (mean, across all concurrent requests)
Transfer rate: 19095.09 [Kbytes/sec] received