Porzuciłem OpenLiteSpeed ​​i wróciłem do starego, dobrego Nginxa

Od 2017 roku, w wolnym czasie (ha!), pomagam mojemu koledze Ericowi Bergerowi w prowadzeniu jego witryny z prognozami pogody dla obszaru Houston, Space City Weather . To ciekawe wyzwanie związane z hostingiem — SCW przeciętnie wykonuje około 20 000–30 000 odsłon stron dla 10 000–15 000 unikalnych użytkowników, co jest stosunkowo łatwym obciążeniem przy minimalnym nakładzie pracy. Kiedy jednak mają miejsce trudne warunki pogodowe — szczególnie latem, kiedy w Zatoce Meksykańskiej czyhają huragany — ruch w witrynie może wzrosnąć do ponad miliona odsłon w ciągu 12 godzin. Obsłużenie tego poziomu ruchu wymaga nieco więcej przygotowań.

Przez bardzo długi czas korzystałem z SCW na stosie backendu składającym się z HAProxy do zakończenia protokołu SSL, Varnish Cache do buforowania wbudowanego i Nginx do rzeczywistej aplikacji serwera WWW – wszystkie obsługiwane przez Cloudflare , aby przejąć większość obciążenia. ( Pisałem o tej konfiguracji obszernie kilka lat temu na Arsie dla ludzi, którzy chcą bardziej szczegółowych szczegółów.) Ten stos został w pełni przetestowany w walce i gotowy pochłonąć każdy ruch, jaki na niego rzucimy, ale był też irytująco skomplikowany , z wieloma warstwami pamięci podręcznej, z którymi trzeba się uporać, a ta złożoność sprawia, że ​​rozwiązywanie problemów jest trudniejsze, niż bym sobie tego życzył.

Dlatego dwa lata temu podczas zimowej przestoju skorzystałem z okazji, aby porzucić trochę złożoności i zredukować stos hostingowy do jednej monolitycznej aplikacji serwera WWW: OpenLiteSpeed .

Koniec ze starym, wejście z nowym

Nie wiedziałem zbyt wiele o OpenLiteSpeed ​​(„OLS” dla znajomych) poza tym, że często wspominano o nim w dyskusjach na temat hostingu WordPress — a ponieważ SCW obsługuje WordPress, zacząłem się tym interesować. Wydawało się, że OLS zyskał wiele pochwał za zintegrowane buforowanie, zwłaszcza gdy w grę wchodził WordPress; rzekomo był dość szybki w porównaniu do Nginx ; i szczerze mówiąc, po pięciu latach administrowania tym samym stosem, zainteresowałem się zmianami. OpenLiteSpeed ​​to było to!

Pierwszą znaczącą zmianą, z którą trzeba było sobie poradzić, było to, że OLS jest konfigurowany głównie poprzez rzeczywisty interfejs GUI, ze wszystkimi irytującymi potencjalnymi problemami, które się z tym wiążą (inny port do zabezpieczenia, kolejne hasło do zarządzania, kolejny publiczny punkt wejścia do backendu, więcej PHP zasoby dedykowane tylko interfejsowi administratora). Ale GUI było szybkie i ujawniało głównie ustawienia, które wymagały ujawnienia. Tłumaczenie istniejącej konfiguracji Nginx WordPress na język OLS było dobrym ćwiczeniem aklimatyzacyjnym i ostatecznie zdecydowałem się na tunele Cloudflare jako akceptowalną metodę ukrycia i teoretycznie bezpiecznej konsoli administracyjnej.

Inną ważną zmianą była wtyczka OLS LiteSpeed ​​Cache do WordPressa, która jest głównym narzędziem używanym do konfigurowania interakcji samego WordPressa z OLS i jego wbudowaną pamięcią podręczną. Jest to ogromna wtyczka zawierająca strony z konfigurowalnymi opcjami , z których wiele dotyczy kierowania wykorzystaniem usługi Quic.Cloud CDN (obsługiwanej przez LiteSpeed ​​Technology, firmę, która stworzyła OpenLiteSpeed ​​i jej płatnego brata LiteSpeed ).

Maksymalne wykorzystanie WordPressa na OLS oznaczało spędzenie czasu na wtyczce i zastanowienie się, która z opcji pomoże, a która zaszkodzi. (Być może nie jest to zaskoczeniem, że istnieje wiele sposobów na wpakowanie się w głupie kłopoty poprzez zbyt agresywne podejście do buforowania.) Na szczęście Space City Weather stanowi doskonały poligon doświadczalny dla serwerów internetowych, będąc ładnie aktywną witryną z bardzo dużą pamięcią podręczną -przyjazne obciążenie pracą, więc opracowałem początkową konfigurację, z której byłem w miarę zadowolony, i wypowiadając starożytne święte słowa rytuału , wcisnąłem wyłącznik. HAProxy, Varnish i Nginx zamilkły, a obciążenie przejął OLS.