story
Do you have a caching service in front maybe?
Yep. Cloudflare is out front, so the actual load on the rasp-pi is mitigated by their content-delivery network.
Then, too, my website is almost entirely simple html with compressed images, so there's not a lot of bytes to shovel.
Here in Berkeley/Oakland, Sonic.net has strung quality fiber-optic, so there's 1Gbit to my house. That lets me keep up with things. However, they only give a dynamic ip address;, so my pi must keep track of its address and tell Cloudflare whenever it changes.
Works surprisingly well - from /top/ I see about several dozen simultaneous users (thank you!), and the cpu temp is about 2 degrees above its normal of 50C
The raspberry pi itself is in the crawlspace under my home, fed through a Ubiquity edge router. Much fun, playing with Unix (oops, I mean Linux) -- sends me back to days of yore when everything happened from your command lines.
1. I met you in Kepler's when Silicon Snake Oil came out and we talked about something and you wrote in the inside "I hear you, John". I don't know what we discussed!
2. I am now Cloudflare's CTO and if you want to avoid the dynamic IP address problem you can use Cloudflare Tunnel to connect to us (rather than us to you). https://www.cloudflare.com/products/tunnel/
The blogs that go down here typically back every request by MySQL (ahem, WordPress) which is totally unnecessary and often actively harmful since MySQL has very low default total connections allowed.
The point being: don't serve requests backed by a database unless the results are likely to change very dynamically!
WordPress is not my favorite thing and some of the available plug-ins do terrible things with MySQL, but the problem is not too low default connections; it's too many PHP workers. WordPress is generally focused enough that most of the wall time is spent in waiting for the database, so you want to optimize for throughput; one or two workers per cpu thread is plenty for that. More concurrency than execution available reduces throughput, so it's better to queue requests in your http layer than to process multiple at once.
Large numbers of MySQL connections are more appropriate when the web pages do a mix of things, but more/mostly idle DB wise; in that case, you might still want persistent connections to reduce round trips before a query, but are less likely to have a query backlog large enough where task switching overhead becomes significant.
