我放棄了 OpenLiteSpeed 並回到了優秀的 Nginx

自 2017 年以來，我利用空閒時間（哈！）幫助我的同事 Eric Berger 託管他的休士頓地區天氣預報網站Space City Weather。這是一個有趣的託管挑戰，在典型的一天中，SCW 可能會為 10,000-15,000 個唯一訪客提供 20,000-30,000 次頁面瀏覽量，這是一個相對容易處理的負載，只需最少的工作。但當發生惡劣天氣事件時，尤其是在夏季，當墨西哥灣颶風潛伏時，該網站的流量可能會在 12 小時內飆升至超過 100 萬頁面瀏覽量。這種程度的流量需要更多的準備來處理。

在很長一段時間裡，我在後端堆疊上運行 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.Cloud CDN 服務的利用率有關（該服務由 LiteSpeed Technology 運營，該公司創建了 OpenLiteSpeed 及其付費兄弟LiteSpeed）。

在 OLS 上充分利用 WordPress 意味著要花一些時間在插件上，弄清楚哪些選項會有所幫助，哪些選項會帶來傷害。（也許毫不奇怪，有很多方法會因為快取過於激進而讓自己陷入愚蠢的麻煩。）幸運的是，Space City Weather 為Web 伺服器提供了一個很好的測試場，它是一個非常活躍的站點，具有非常高的快取-友好的工作量，所以我敲定了一個我相當滿意的起始配置，並在說出儀式的古老聖言的同時，打開了切換開關。HAProxy、Varnish 和 Nginx 都沉默了，OLS 承擔了負荷。