[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.