I abandoned OpenLiteSpeed and went back to good ol’ Nginx
Adventures in server babysitting —
One weather site’s sudden struggles, and musings on why change isn’t always good.

Enlarge / Ish is on fire, yo.
Since 2017, in what spare time I have (ha!), I help my colleague Eric Berger host his Houston-area weather forecasting site, Space City Weather. It’s an interesting hosting challenge—on a typical day, SCW does maybe 20,000–30,000 page views to 10,000–15,000 unique visitors, which is a relatively easy load to handle with minimal work. But when severe weather events happen—especially in the summer, when hurricanes lurk in the Gulf of Mexico—the site’s traffic can spike to more than a million page views in 12 hours. That level of traffic requires a bit more prep to handle.
Lee Hutchinson
For a 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 actual web server application—all fronted by Cloudflare to absorb the majority of the load. (I wrote about this setup at length on Ars a few years ago for folks who want some more in-depth details.) This stack was fully battle-tested and ready to devour whatever traffic we threw at it, but it was also annoyingly complex, with multiple cache layers to contend with, and that complexity made troubleshooting issues more difficult than I would have liked.
So during some winter downtime two years ago, I took the opportunity to jettison some complexity and reduce the hosting stack down to a single monolithic web server application: OpenLiteSpeed.
Out with the old, in with the new
I didn’t know too much about OpenLiteSpeed (“OLS” to its friends) other than that it’s mentioned a bunch in discussions about WordPress hosting—and since SCW runs WordPress, I started to get interested. OLS seemed to get a lot of praise for its integrated caching, especially when WordPress was involved; it was purported to be quite quick compared to Nginx; and, frankly, after five-ish years of admining the same stack, I was interested in changing things up. OpenLiteSpeed it was!
Enlarge / The OLS admin console, showing vhosts. This is from my personal web server rather than the Space City Weather server, but it looks the same. If you want some deeper details on the OLS config I was using, check my blog. Yeah, I still have a blog. I’m old.
Lee Hutchinson
The first significant adjustment to deal with was that OLS is primarily configured through an actual GUI, with all the annoying potential issues that brings with it (another port to secure, another password to manage, another public point of entry into the backend, more PHP resources dedicated just to the admin interface). But the GUI was fast, and it mostly exposed the settings that needed exposing. Translating the existing Nginx WordPress configuration into OLS-speak was a good acclimation exercise, and I eventually settled on Cloudflare tunnels as an acceptable method for keeping the admin console hidden away and notionally secure.

Enlarge / Just a taste of the options that await within the LiteSpeed Cache WordPress plugin.
Lee Hutchinson
The other major adjustment was the OLS LiteSpeed Cache plugin for WordPress, which is the primary tool one uses to configure how WordPress itself interacts with OLS and its built-in cache. It’s a massive plugin with pages and pages of configurable options, many of which are concerned with driving utilization of the Quic.Cloud CDN service (which is operated by LiteSpeed Technology, the company that created OpenLiteSpeed and its for-pay sibling, LiteSpeed).
Getting the most out of WordPress on OLS meant spending some time in the plugin, figuring out which of the options would help and which would hurt. (Perhaps unsurprisingly, there are plenty of ways in there to get oneself into stupid amounts of trouble by being too aggressive with caching.) Fortunately, Space City Weather provides a great testing ground for web servers, being a nicely active site with a very cache-friendly workload, and so I hammered out a starting configuration with which I was reasonably happy and, while speaking the ancient holy words of ritual, flipped the cutover switch. HAProxy, Varnish, and Nginx went silent, and OLS took up the load.
I abandoned OpenLiteSpeed and went back to good ol’ Nginx Read More »

























![Hand-cut tokens and make-do squares for an early version of <em>Thirst</em>.” height=”960″ src=”https://cdn.arstechnica.net/wp-content/uploads/2023/12/IMG_3964-Large.jpeg” width=”1280″></img><figcaption>
<p>Hand-cut tokens and make-do squares for an early version of <em>Thirst</em>.</p>
<p>Kevin Purdy</p>
</figcaption></figure>
<p>The way <i>CorpVamp</i>/<i>Thirst</i> should go is that each night, a vampire wakes up, loses a little blood, then sets out to get much more back by exploring a Victorian city. In populated neighborhoods, a vampire can feast on people—but doing so generates a board-altering Consequence, such as roving security guards or citizens discovering bodies. Vampires accumulate victims and hypnotize them for Influence, depending on who the victims are (“Judge” versus “Roustabout,” for example), turn them into “Baby Vampires,” or simply keep them as blood stock. You win by accruing victory points for various misdeeds and achievements.</p>
<p>One player, who told the designers that a different game’s play-test saw him “break the game in 10 minutes,” seemed bothered by how Consequences can be triggered by a single player’s actions but affect all players. Another has a hard time keeping track of the tokens for influence, movement, and blood, and when to move them on and off the board. That’s called “mess testing,” Schofield tells me, and he’s working on it. Some things will be easier to learn and use when the pieces have better designs and materials. But the <i>CorpVamp</i> team can’t jump to that stage until the mechanics are locked down.</p>
<p>As that group finishes a test, another group sits down immediately, having stood nearby to ensure their chance. Schofield and Broadwater won’t lack for players in their three-hour slot. That tells the team there’s “evidence of a market,” that their game has “stopping power” and “shelf value,” despite its obscurity, Schofield says. But there’s lots of work still to be done in alpha. “The costs of powers are too high, the powers aren’t <i>badass enough</i> [emphasis his], and the tactile movement of placing cubes and flipping tokens isn’t quite right,” he later tells me.</p>
<p>After more iterations and some “blind” play tests (players learning, playing, and finishing the game without creator guidance), the game will be in beta, and the team will get closer to pinning down the look and feel of the game with illustrators and designers. Since their schedules only afford them roughly three hours of dedicated collaboration time every week, they lean on what they’ve learned from their product-oriented day jobs. “Frequent iterations and small feedback loops will iron things out,” Schofield says. “Process wins.”</p>
<p>Then they can “enjoy the problems of production and distribution logistics.” After that, “We’ll sell copies of <i>Thirst</i> at the next PAX Unplugged.”</p>
<figure><img loading=](https://cdn.arstechnica.net/wp-content/uploads/2023/12/who_knew-scaled.jpg)











