Since 2017, in what spare time I’ve (ha!), I assist my colleague Eric Berger host his Houston-area climate forecasting web site, House 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 straightforward 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 visitors can spike to greater than one million web page views in 12 hours. That stage of 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 utility—all fronted by Cloudflare to soak up nearly all of the load. (I wrote about this setup at size on Ars a number of years in the past for people who need some extra in-depth particulars.) This stack was absolutely battle-tested and able to devour no matter visitors we threw at it, however it was additionally annoyingly advanced, with a number of cache layers to take care of, and that complexity made troubleshooting points harder than I might have appreciated.
So throughout some winter downtime two years in the past, I took the chance to jettison some complexity and cut back the internet hosting stack right down to a single monolithic internet server utility: OpenLiteSpeed.
Out with the outdated, in with the brand new
I didn’t know an excessive amount of about OpenLiteSpeed (“OLS” to its buddies) apart 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 numerous 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 eager about altering issues up. OpenLiteSpeed it was!
Lee Hutchinson
The primary vital adjustment to cope with was that OLS is primarily configured by way of 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 great acclimation train, and I finally settled on Cloudflare tunnels as an appropriate technique for preserving 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 software one makes use of to configure how WordPress itself interacts with OLS and its built-in cache. It’s a large plugin with pages and pages of configurable choices, a lot 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, House Metropolis Climate offers an excellent testing floor for internet servers, being a properly energetic web site with a really cache-friendly workload, and so I hammered out a beginning configuration with which I used to be fairly pleased and, whereas talking the traditional holy phrases of formality, flipped the cutover change. HAProxy, Varnish, and Nginx went silent, and OLS took up the load.
