Я відмовився від OpenLiteSpeed ​​і повернувся до старого доброго Nginx

З 2017 року, у вільний час (га!), я допомагаю своєму колезі Еріку Бергеру розміщувати його сайт прогнозу погоди в Х’юстоні Space City Weather . Це цікаве завдання щодо хостингу — у звичайний день SCW робить, можливо, 20 000–30 000 переглядів сторінок для 10 000–15 000 унікальних відвідувачів, що є відносно легким навантаженням, яке можна впоратися з мінімальною роботою. Але коли трапляються суворі погодні явища, особливо влітку, коли в Мексиканській затоці чатують урагани, відвідуваність сайту може зрости до понад мільйона переглядів сторінок за 12 годин. Такий рівень трафіку вимагає трохи більше підготовки.

Протягом дуже тривалого часу я використовував SCW на фоновому стеку, який складався з HAProxy для завершення SSL, Varnish Cache для внутрішнього кешування та Nginx для фактичної програми веб-сервера — усе це передавало Cloudflare , щоб поглинати більшу частину навантаження. ( Я детально писав про це налаштування на Ars кілька років тому для людей, які хочуть отримати більш детальну інформацію.) Цей стек був повністю випробуваний у боях і готовий пожерти будь-який трафік, який ми на нього кинули, але він також був надзвичайно складним. , з декількома рівнями кешу, з якими доводиться боротися, і ця складність ускладнювала вирішення проблем, ніж мені хотілося б.

Тож під час деякого зимового простою два роки тому я скористався можливістю відмовитися від деяких складнощів і скоротити стек хостингу до однієї монолітної програми веб-сервера: OpenLiteSpeed .

Зі старим, з новим

Я не надто багато знав про OpenLiteSpeed ​​(«OLS» для його друзів), окрім того, що його багато згадували в дискусіях про хостинг WordPress — і оскільки SCW запускає WordPress, я почав цікавитися. OLS, здається, отримав багато похвали за інтегроване кешування, особливо коли був задіяний WordPress; він нібито був досить швидким порівняно з Nginx ; і, відверто кажучи, після п’яти років адміністрування того самого стеку я захотів щось змінити. OpenLiteSpeed ​​це було!

Перше значне коригування, з яким потрібно було впоратися, полягало в тому, що OLS налаштовується в основному через фактичний графічний інтерфейс користувача з усіма неприємними потенційними проблемами, які він приносить (ще один порт для захисту, інший пароль для керування, ще одна публічна точка входу в серверну частину, більше PHP ресурси, присвячені лише інтерфейсу адміністратора). Але графічний інтерфейс був швидким і здебільшого показував параметри, які потрібно було відкрити. Переклад наявної конфігурації Nginx WordPress на OLS-мову був гарною вправою для звикання, і зрештою я зупинився на тунелях Cloudflare як прийнятному методі для того, щоб тримати консоль адміністратора прихованою та уявно безпечною.

Іншим важливим коригуванням був плагін OLS LiteSpeed ​​Cache для WordPress, який є основним інструментом, який використовується для налаштування того, як сам WordPress взаємодіє з OLS і його вбудованим кешем. Це величезний плагін зі сторінками та сторінками параметрів, які можна налаштувати , багато з яких пов’язані із стимулюванням використання служби CDN Quic.Cloud (якою керує LiteSpeed ​​Technology, компанія, яка створила OpenLiteSpeed ​​і її платний брат LiteSpeed ).

Щоб отримати максимальну віддачу від WordPress на OLS, потрібно витратити деякий час на плагін, з’ясовуючи, які з варіантів допоможуть, а які зашкодять. (Можливо, не дивно, що існує багато способів створити собі дурну кількість неприємностей через занадто агресивне кешування.) На щастя, Space City Weather є чудовим випробувальним полігоном для веб-серверів, будучи досить активним сайтом із дуже кеш-пам’яттю. -дружнє робоче навантаження, тож я виробив початкову конфігурацію, якою був досить задоволений, і, промовляючи давні священні слова ритуалу , натиснув перемикач. HAProxy, Varnish і Nginx замовкли, а OLS взяв на себе навантаження.