自2017年以来，在我的业余时间(哈!)，我帮助我的同事埃里克·伯杰主持他的休斯顿地区天气预报网站，太空城天气。这是一个有趣的托管挑战——在一个典型的日子里，SCW可能会有20,000-30,000个页面浏览量到10,000-15,000个独立访问者，这是一个相对容易的负载，可以用最少的工作来处理。但是当恶劣的天气事件发生时——尤其是在夏天，飓风潜伏在墨西哥湾的时候——网站的流量可以在12小时内飙升到超过一百万的页面浏览量。这种水平的流量需要更多的准备来处理。
很长一段时间以来，我在一个后端堆栈上运行SCW，该后端堆栈由用于SSL终止的HAProxy，用于盒上缓存的Varnish Cache和用于实际web服务器应用程序的Nginx组成，所有这些都由Cloudflare前端来吸收大部分负载。(几年前，我曾在Ars上详细介绍过这种设置，供想了解更深入细节的人使用。)这个堆栈经过了全面的实战测试，随时准备吞噬我们投入的任何流量，但它也非常复杂，需要处理多个缓存层，这种复杂性使得故障排除比我希望的要困难得多。
因此，在两年前的冬季停机期间，我抓住机会抛弃了一些复杂性，并将托管堆栈减少到一个单一的整体web服务器应用程序:OpenLiteSpeed。
我对OpenLiteSpeed(对它的朋友来说是“OLS”)了解不多，只知道它在关于WordPress托管的讨论中被提到过很多次——自从SCW运行WordPress以来，我开始对它感兴趣。OLS似乎因为它的集成缓存得到了很多赞扬，特别是当WordPress参与其中时;据说它比Nginx快得多;坦率地说，在管理同一个堆栈五年多之后，我对改变一些东西很感兴趣。OpenLiteSpeed !
广告要处理的第一个重大调整是，OLS主要是通过一个实际的GUI配置的，伴随着它带来的所有恼人的潜在问题(另一个需要保护的端口、另一个需要管理的密码、另一个进入后端的公共点、更多专门用于管理界面的PHP资源)。但是GUI很快，而且它主要暴露了需要暴露的设置。将现有的Nginx WordPress配置转换为ols语言是一个很好的适应练习，我最终决定使用Cloudflare隧道作为一种可接受的方法，以保持管理控制台的隐藏和理论上的安全。
另一个主要的调整是WordPress的OLS LiteSpeed缓存插件，它是用来配置WordPress本身如何与OLS及其内置缓存交互的主要工具。这是一个庞大的插件，有许多页面的可配置选项，其中许多都与驱动Quic的利用率有关。云CDN服务(由LiteSpeed Technology运营，该公司创建了OpenLiteSpeed及其付费兄弟LiteSpeed)。
在OLS上充分利用WordPress意味着花一些时间在插件上，弄清楚哪些选项是有益的，哪些是有害的。(也许不足为奇的是，有很多方法会因为过于激进地使用缓存而让自己陷入愚蠢的麻烦中。)幸运的是，Space City Weather为web服务器提供了一个很好的测试场所，它是一个非常活跃的网站，具有非常适合缓存的工作负载，所以我制定了一个我相当满意的初始配置，一边说着古老的神圣仪式，一边拨动了切换开关。HAProxy, Varnish和Nginx静默，OLS承担了负载。