[kragen]

Oh, I was using a shell script spawned from inetd as the lowest-tech, most primitive, worst-performance simple way of running a web server. A random PHP-running blog will easily handle tens of millions of hits a day unless you way overcomplicate it.

[j45]

Millions of hits a day doesn't seem to be the correct metric for an HN front page traffic spike.

Concurrent connections per second is likely much more relevant, and in that case, one can put the most basic proxy or cache in front of the webpage to help a great deal, if not Cloudflare.

[kragen]

"Concurrent connections" and "connections per second" are two different measures which you are confusing. The second one is basically the same thing as "hits per day", and the first one isn't relevant.

[j45]

I can't seem to reply to the other quote.

Concurrent connections is the number of simultaneous connections a server can handle, something little wordpress sites not behind anything to help often get slammed with on the regular.

[kragen]

Wordpress is kind of a pig, yeah. But unless you're running WebSocket or server-sent events or some other Comet thing from Wordpress, you can solve the concurrent-connections problem just by limiting the number of concurrent PHP processes your server runs (MaxRequestWorkers in Apache), which may or may not be set to a reasonable default like 20 normally. Additional burst clients will either pile up in the kernel's connection queue or have to retry their SYN packets if the kernel's connection queue is full.

The reason you need more than one concurrent connection (again, barring some kind of Comet) is that some clients take a significantly nonzero amount of time to finish receiving the response, at which point PHP has generally already finished executing but is still taking up RAM, which is what limits the number of concurrent connections you can handle with Wordpress. But really all you need to do is not go into swap when you hit an overload, and Bob's your uncle.

Depending on how it's configured, Wordpress may still not be able to answer new requests as soon as they come in, but that's not a problem of the number of concurrent connections; it's a problem of the number of hits per second.

You can decouple the number of concurrent connections from the amount of RAM you're burning in PHP by using FastCGI, or just plain old CGI, or nginx (with probably FastCGI), or putting a reverse proxy in front of Apache, or just about anything except mod_php, but you very rarely need to. There just aren't that many people on 14.4kbps modems any more, and your web server has literal gigabytes of RAM.

You don't need Cloudflare unless you're getting DDoSed.

[j45]

Wordpress sites served from a shared webhost get slammed by HN and go unresponsive all the time which can amount to a mini ddos.

Wordpress plugins can cache the site but really in 2025 it should be built in instead of the forced paid plugin route that has really made Wordpress a suboptimal experience.