The error is that there are too many connections, not that it took too long to establish them. MySQL is generally pretty quick about establishing connections (although you can have issues w/ reverse DNS taking forever; it's best to turn that off and do access control by ips).

Ideally, a blog can be cached to static html (regen pages when owner adds an entry and if comments are self hosted, regen when a comment is added/approved). Even so, it looks like there are too many php processes running compared to mysql connections allowed; lowering the php processes will probably lead to better throughput than ramping up mysql connections.

Also, last I checked, at least Debian ships with an Apache max-workers setting greater than the MySQL max-connections setting out of the box, pretty much guaranteeing errors like these even on a single virtualhost under load.

Or generally possible directly with web requests. Pretty much everything is torn down at the end of each request. (Yeah PHP-FPM slightly muddies the waters)

With MySQL it's not necessarily always a good thing to persist connections. If your script dies, you lost that connection as a resource until it's killed for being idle.

Most DBs all have their own connection pooling mechanisms that don't work the same way, so we need to look into each to see if it's worth it. Caching though (query as well as HTML), is usually always a good idea.