З 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 це було!
Advertisement
Перше значне коригування, з яким потрібно було впоратися, полягало в тому, що OLS налаштовується в основному через фактичний графічний інтерфейс користувача з усіма неприємними потенційними проблемами, які він приносить (ще один порт для захисту, інший пароль для керування, ще одна публічна точка входу в серверну частину, більше PHP ресурси, присвячені лише інтерфейсу адміністратора). Але графічний інтерфейс був швидким і здебільшого показував параметри, які потрібно було відкрити. Переклад існуючої конфігурації Nginx WordPress на мову OLS був гарною вправою для звикання, і зрештою я зупинився на тунелях Cloudflare як прийнятному методі для того, щоб тримати консоль адміністратора прихованою та уявно безпечною.
Іншим важливим коригуванням був плагін OLS LiteSpeed Cache для WordPress, який є основним інструментом, який використовується для налаштування того, як сам WordPress взаємодіє з OLS і його вбудованим кешем. Це величезний плагін зі сторінками та сторінками параметрів, які можна налаштувати, багато з яких пов’язані із стимулюванням використання служби Quic.Cloud CDN (якою керує LiteSpeed Technology, компанія, яка створила OpenLiteSpeed і її платного брата LiteSpeed).
Щоб отримати максимальну віддачу від WordPress на OLS, потрібно було витратити деякий час на плагін, з’ясовуючи, які з варіантів допоможуть, а які зашкодять. (Можливо, не дивно, що існує багато способів створити собі дурну кількість неприємностей через занадто агресивне кешування.) На щастя, Space City Weather є чудовим випробувальним полігоном для веб-серверів, будучи досить активним сайтом із дуже кеш-пам’яттю. -дружнє робоче навантаження, тож я виробив початкову конфігурацію, якою був досить задоволений, і, промовляючи давні священні слова ритуалу, натиснув перемикач. HAProxy, Varnish і Nginx замовкли, а OLS взяв на себе навантаження.
Сторінка: 1 2 3 4 5 Наступна &rar;
