Which I guess works, but is not that interesting of a technical read? If you were not on wordpress, I bet you could have served that load from a single VM on a cloud provider, with the ability to scale as needed.
Which I guess works, but is not that interesting of a technical read? If you were not on wordpress, I bet you could have served that load from a single VM on a cloud provider, with the ability to scale as needed.
* Dedicated hardware server—no shared hosting
* Gigabit uplink to handle burst traffic
* Varnish cache with lots of RAM
* Plugin-light WordPress installation
* Off-box stats via WordPress/Jetpack
* Cloudflare as a CDN
* No heavy dependencies (i.e., ad networks)Between August 22 and August 30, Cloudflare served over five terabytes of cached Space City Weather content via Cloudflare’s CDN. Only about 145GB worth of requests had to be served by the Space City Weather Web server itself. [...] Looking at raw requests instead of bytes, Cloudflare handled about 88 percent of those, too, with only about 12 percent of requests passed back up the chain to the origin server.
The origin server ended up seeing peaks of 50 RPS, most of that was absorbed by Varnish. I guess 50 RPS is a lot for WordPress, though I'm surprised given the origin server is a decent box:
The server has a quad-core Xeon E3-1230 CPU, 16GB of RAM, and mirrored R1 SSDs.
Clarification: the "caching plugins" are just administrative tie-ins to Varnish and Cloudflare, not actual plugins that make WP perform any caching at the WP application layer. The site doesn't use W3 Total Cache or WP Super Cache or any other popular WP cache plugin.
(edit - at the wordpress application layer, i mean—talking about that specifically, not layer 7 cache in general)