Since 2017, in what spare time I’ve (ha!), I assist my colleague Eric Berger host his Houston-area climate forecasting website, Area Metropolis Climate. It’s an attention-grabbing internet hosting problem—on a typical day, SCW does perhaps 20,000–30,000 web page views to 10,000–15,000 distinctive guests, which is a comparatively simple load to deal with with minimal work. However when extreme climate occasions occur—particularly in the summertime, when hurricanes lurk within the Gulf of Mexico—the positioning’s site visitors can spike to greater than one million web page views in 12 hours. That degree of site visitors requires a bit extra prep to deal with.
Lee Hutchinson
For a really very long time, I ran SCW on a backend stack made up of HAProxy for SSL termination, Varnish Cache for on-box caching, and Nginx for the precise internet server software—all fronted by Cloudflare to soak up nearly all of the load. (I wrote about this setup at size on Ars a couple of years in the past for folk who need some extra in-depth particulars.) This stack was absolutely battle-tested and able to devour no matter site visitors we threw at it, nevertheless it was additionally annoyingly complicated, with a number of cache layers to take care of, and that complexity made troubleshooting points harder than I’d have preferred.
So throughout some winter downtime two years in the past, I took the chance to jettison some complexity and scale back the internet hosting stack all the way down to a single monolithic internet server software: OpenLiteSpeed.
Out with the outdated, in with the brand new
I didn’t know an excessive amount of about OpenLiteSpeed (“OLS” to its associates) aside from that it is talked about a bunch in discussions about WordPress internet hosting—and since SCW runs WordPress, I began to get . OLS appeared to get a variety of reward for its built-in caching, particularly when WordPress was concerned; it was presupposed to be fairly fast in comparison with Nginx; and, frankly, after five-ish years of admining the identical stack, I used to be interested by altering issues up. OpenLiteSpeed it was!
Lee Hutchinson
The primary important adjustment to take care of was that OLS is primarily configured by an precise GUI, with all of the annoying potential points that brings with it (one other port to safe, one other password to handle, one other public level of entry into the backend, extra PHP sources devoted simply to the admin interface). However the GUI was quick, and it largely uncovered the settings that wanted exposing. Translating the prevailing Nginx WordPress configuration into OLS-speak was a very good acclimation train, and I finally settled on Cloudflare tunnels as an appropriate technique for retaining the admin console hidden away and notionally safe.
Lee Hutchinson
The opposite main adjustment was the OLS LiteSpeed Cache plugin for WordPress, which is the first device one makes use of to configure how WordPress itself interacts with OLS and its built-in cache. It’s an enormous plugin with pages and pages of configurable choices, lots of that are involved with driving utilization of the Quic.Cloud CDN service (which is operated by LiteSpeed Expertise, the corporate that created OpenLiteSpeed and its for-pay sibling, LiteSpeed).
Getting probably the most out of WordPress on OLS meant spending a while within the plugin, determining which of the choices would assist and which might damage. (Maybe unsurprisingly, there are many methods in there to get oneself into silly quantities of hassle by being too aggressive with caching.) Happily, Area Metropolis Climate supplies an amazing testing floor for internet servers, being a properly energetic website with a really cache-friendly workload, and so I hammered out a beginning configuration with which I used to be moderately pleased and, whereas talking the traditional holy phrases of formality, flipped the cutover swap. HAProxy, Varnish, and Nginx went silent, and OLS took up the load.