Автор: Иван Богданов, Технический писатель 

В IT-сообществе споры бывают горячими. Vim vs Emacs, tabs vs spaces, PHP vs всё остальное — но есть споры поспокойнее, где побеждает не сила привычки, а цифры. Один из таких — выбор веб-сервера для WordPress.

Маркетплейс приложений HOSTKEY
Арендуй сервер с предустановленным WordPress с OpenLiteSpeed или LEMP.

Посмотреть

LEMP — классическая связка Linux, Nginx (Engine-X), MySQL/MariaDB, PHP. Проверенный временем стек, который используют миллионы сайтов. OpenLiteSpeed — относительно новый веб-сервер с собственной реализацией PHP (LSPHP) и встроенным кешированием. Позиционируется как быстрая альтернатива Apache и Nginx.

Статистика наших заказов показывает интересную картину: 63% клиентов выбирают классический LEMP-стек (Nginx + PHP-FPM), 37% — OpenLiteSpeed с предустановленным WordPress. Соотношение почти два к одному в пользу проверенного решения. Значит ли это, что LEMP объективно лучше? Или просто привычнее? Мы решили не гадат��, а померить. Два идентичных сервера, одинаковый WordPress, реальные нагрузочные тесты. Никаких синтетических бенчмарков из маркетинговых материалов — только живые цифры с реальных серверов.

Что тестировали

Конфигурация серверов

Сервер 1:OpenLiteSpeed

  • Ubuntu 22.04 LTS;

  • OpenLiteSpeed 1.8.5 + LSPHP 8.5;

  • MariaDB 11.4;

  • Docker Compose (4 контейнера: веб-сервер, БД, Redis, phpMyAdmin).

Сервер 2:LEMP

  • Ubuntu 22.04 LTS;

  • Nginx 1.22.1 + PHP 8.3 FPM;

  • MariaDB 10.6.16;

  • Docker (монолитный контейнер adhocore/lemp:8.3).

Оба сервера получили одинаковые лимиты: 1.847 Гб ОЗУ, идентичное железо. На каждый установили WordPress 6.7 с темой Astra, создали 16 тестовых постов и 7 страниц. Никаких плагинов оптимизации — только базовое кеширование: LSCache для OpenLiteSpeed, WP Super Cache для LEMP.

OpenLiteSpeed поставлялся с предустановленным WordPress, поэтому достаточно было завершить установку через веб-интерфейс. LEMP — это чистый стек без WordPress, установка выполнялась вручную через WP-CLI. Ручная установка потребовала больше усилий (включая отладку проблемы localhost/127.0.0.1), но при этом мы получили чистую конфигурацию без предустановленных оптимизаций.

Методология

Тесты запускались с третьего сервера (нейтральная площадка) через Apache Bench. Перед каждым тестом выполнялся прогрев кеша десятью запросами. Мы измеряли RPS (requests per second), latency, потребление CPU и RAM.

Сценарии тестирования:

  • Легкая нагрузка: 10 одновременных пользователей;

  • Средняя нагрузка: 50 одновременных;

  • Высокая нагрузка: 100 одновременных;

  • Экстремальная: 200, 300, 500 одновременных;

  • Динамический контент: поиск WordPress (без кеша).

Стоит учесть, что Apache Bench генерирует идеальную равномерную нагрузку и все запросы одинаковые, с одной точки, без задержек. Это не имитация реальных пользователей. Реальный трафик разнородный: разные страницы, боты, краулеры, множественные ресурсы на одной странице. Именно поэтому AB полезен для базового сравнения. Он показывает максимальную теоретическую производительность стека без переменных. Если один стек в 9 раз быстрее другого на синтетике, на реальном трафике разница будет меньше, при этом направление останется тем же.

16 постов и 7 страниц — это минималистичный контент. На сайте с тысячей постов кеш будет больше, появятся дополнительные факторы (размер кеша на диске, обновление кеша, потребление памяти). Однако базовая механика кеширования проявляется уже на малом объеме. Мы тестируем не WordPress как платформу, а разницу между двумя способами отдачи одного и того же контента. Наша цель: не симулировать прод, а изолировать переменную. Что быстрее отдает статическую HTML-страницу: Nginx с PHP-FPM или OpenLiteSpeed с LSAPI? Всё остальное — константа.

Мы не тестировали холодный старт (все измерения после прогрева кеша), долговременную стабильность (тесты длились минуты, не недели), SSL/TLS overhead и работу на bare metal вместо Docker. Также серверы использовали разные версии PHP (8.5 vs 8.3) и MariaDB (11.4 vs 10.6). Это связано с дефолтными конфигурациями образов. Apache Bench генерирует равномерную нагрузку, то есть это не боты, не краулеры, не реальные пользователи с разной географией. 16 постов не равнозначны 10 000 постов с большим кешем на диске. Простой поиск WordPress не сравнить с WooCommerce с фильтрами товаров.

Эти тесты отвечают на один вопрос: что быстрее отдает закешированный HTML: LEMP или OpenLiteSpeed. Не «что лучше для продакшена» (зависит от контекста), а где базовая разница в производительности. Для финального решения нужны тесты на вашем контенте, с вашей нагрузкой, на вашем железе.

Результаты тестирования

Статический контент с кешем

Здесь OpenLiteSpeed ожидаемо должен был выиграть, так как LSCache считается одним из лучших решений для кеширования, но масштаб разницы удивил.

10 одновременных пользователей

RPS

Latency (мсек)

LEMP

61.64

162

OpenLiteSpeed

559.26

17.88

Разница в 9 раз! OpenLiteSpeed обрабатывает запросы в девять раз быстрее при той же нагрузке.

50 одновременных пользователей

RPS

Latency (мсек)

LEMP

60.56

825

OpenLiteSpeed

604.98

82.65

Разница уже в 10 раз! При росте нагрузки LEMP не ускорился, так как latency выросла с 162 до 825 миллисекунд. OpenLiteSpeed показал стабильные 600+ RPS..

100 одновременных пользователей

RPS

Latency (мсек)

LEMP

63.97

1,563

OpenLiteSpeed

550.48

181.66

LEMP уперся в потолок около 60 RPS. При удвоении нагрузки latency выросла почти вдвое (825 >> 1563 мсек), но throughput остался на месте. OpenLiteSpeed держит 550 RPS, latency выросла незначительно.

Перцентили latency (50 одновременных пользователей)

Перцентиль

LEMP (мсек)

OpenLiteSpeed (мсек)

50%

798

80

90%

895

103

99%

1,117

126

99% пользователей OpenLiteSpeed получают ответ быстрее, чем половина пользователей LEMP.

Экстремальные нагрузки

200 одновременных пользователей:

RPS

Latency (мсек)

LEMP

61.13

3,262

OpenLiteSpeed

300.81

664

Разница в 5 раз.

300 одновременных пользователей:

RPS

Latency (мсек)

LEMP

54.23

5,531

OpenLiteSpeed

239.56

1,252

Разница в 4.4 раза.

500 одновременных пользователей:

RPS

Latency (мсек)

failed requests

LEMP

57.22

8,738

0

OpenLiteSpeed

crashed после 1,671 запроса из 5,000

При 500 одновременных пользователях OpenLiteSpeed начал сбрасывать соединения с ошибкой Connection reset by peer. LEMP продолжил работать, пусть и медленно, затрачивая почти 9 секунд на запрос, но без отказов.

Большинству сайтов 500 одновременных пользователей не грозит. Согласно исследованию HubSpot, 46% сайтов получают менее 15 000 посетителей в месяц — при типичном распределении трафика это означает пиковую нагрузку в десятки одновременных соединений, а не сотни. Тест на экстремальную нагрузку показывает не просто предел производительности, а характер деградации.

LEMP замедляется, но не ломается: становится медленнее (9 секунд на запрос), но продолжает работать. Каждый пользователь получает ответ, пусть и с задержкой.

OpenLiteSpeed деградирует катастрофически: начинает сбрасывать соединения. Часть пользователей не получает ответ вообще.

Для малого блога это неважно. Для сайта, который может попасть в топ Hacker News или Reddit, — критично. Вирусная статья может принести непредсказуемый всплеск трафика. LEMP его переживет медленно, OLS может упасть.

Это не делает OLS плохим выбором, лишь определяет границы применимости. До 300 одновременных пользователей он быстрее и эффективнее. Выше 300 нужен LEMP или горизонтальное масштабирование (несколько инстансов OLS за балансировщиком).

Вердикт примерно такой: OpenLiteSpeed в 4–10 раз быстрее на статическом контенте, но имеет предел около 300–400 одновременных подключений. LEMP медленный, но стабильный.

Динамический контент без кеша

Поисковые запросы WordPress не кешируются — каждый запрос проходит через PHP и базу данных. Здесь должны проявиться различия в обработке динамического контента.

Первый запуск (дефолтная конфигурация OpenLiteSpeed)

RPS

Latency (мсек)

99% перцентиль (мсек)

LEMP

49.78

173

296

OpenLiteSpeed

6.84

144

59,530

LEMP быстрее в 7,3 раза, но главная проблема OpenLiteSpeed — не медианная latency, а 99% перцентиль: почти минута на один процент запросов. 

Логи OpenLiteSpeed показали проблему:

[NOTICE] No request delivery notification has been received from LSAPI application, possible dead lock.
[NOTICE] ExtConn timed out while processing.
LSAPI deadlock.

Дефолтная конфигурация OpenLiteSpeed использует всего 10 PHP worker процессов (PHP_LSAPI_CHILDREN=10). При 10 параллельных поисковых запросах все процессы заняты, новые запросы встают в очередь. initTimeout установлен в 60 секунд — именно столько система ждет перед сбросом соединения.

Меняем конфигурацию:

  • maxConns:10 >> 100

  • PHP_LSAPI_CHILDREN:10 >> 50

  • initTimeout:60 >> 30

  • retryTimeout:0 >> 10

  •  max_execution_time:0 >> 30

Результаты после исправлений:

RPS

Latency (мсек)

99% перцентиль (мсек)

LEMP

54.41

161

242

OpenLiteSpeed

15.99

579

1,056

99% перцентиль OpenLiteSpeed улучшился в 56 раз (с 60 секунд до 1 секунды), но LEMP всё равно быстрее в 3,4 раза на динамическом контенте.

LEMP значительно лучше обрабатывает динамические запросы. OpenLiteSpeed требует обязательной настройки LSAPI для корректной работы — из коробки он не готов к параллельным динамическим запросам.

Потребление ресурсов

Синтетические тесты RPS показывают теоретическую производительность. Потребление ресурсов это уже практическая метрика. Сколько стоит VPS с 1 Гб ОЗУ? Сколько с 2 Гб? Если OLS укладывается в 1 Гб, а LEMP требует 2 Гб, то экономия реальна. Тариф с 2 Гб дороже на 20–25% и на длинной дистанции это ощутимая разница в бюджете. И это не абстрактная «эффективность», а деньги на счете хостинг-провайдера.

Тест: 50 одновременных пользователей, 2000 запросов, статический контент с кешем.

CPU:

  • LEMP:Peak 194.82% (~2 ядра), Idle ~1%

  • OpenLiteSpeed:Peak 110.81% (~1 ядро), Idle ~0.4%

OpenLiteSpeed использует в 1.76 раза меньше CPU при обработке той же нагрузки.

RAM:

  • LEMP:Peak 465.4 МиБ (24.6% от лимита), Idle 419 МиБ

  • OpenLiteSpeed:Peak 42.68 МиБ (2.25% от лимита), Idle 35 МиБ

OpenLiteSpeed использует в 11 раз меньше оперативной памяти. Для VPS с 1 Гб RAM это критическая разница: LEMP съедает почти половину, OpenLiteSpeed — 40 мегабайт.

Пропускная способность:

  • LEMP:6,928 Кб/сек

  • OpenLiteSpeed:39,227 Кб/сек

Разница в 5,7 раза. OpenLiteSpeed не просто быстрее отвечает, он пропускает больше данных в секунду.

TTFB (Time To First Byte)

Измеряем время до первого байта на 10 последовательных запросах к главной странице с кешем.

  • LEMP:среднее 0.807 секунды (807 миллисекунд)

  • OpenLiteSpeed:среднее 0.023 секунды (23 миллисекунды)

OpenLiteSpeed отдает первый байт в 35 раз быстрее. Для SEO и Core Web Vitals это важный показатель, так как Google учитывает TTFB при ранжировании.

Выводы

Для контентных сайтов (блоги, новости, корпоративные визитки) выбор очевиден — OpenLiteSpeed. 9-кратный прирост на кешируемом контенте перевешивает просадку на некешируемых запросах. TTFB в 23 миллисекунды вместо 807 — это не абстрактная метрика, а реальное преимущество для метрик Google PageSpeed. Потребление RAM серверным стеком 43 Мб вместо 465 Мб — это возможность разместить сайт на дешевом тарифе. На VPS за 238₽/месяц вместо 294₽/месяц экономия за год составит 672 рубля — на нескольких проектах набегает ощутимая сумма.

Ограничение только в нашей конфигурации: предел оказался около 300 одновременных пользователей. При 500 пользователях OpenLiteSpeed начинает сбрасывать соединения. Для малого и среднего сайта это не проблема. Для проекта, который может попасть в топ Reddit или Хабр, уже критично.

Для динамических приложений безопаснее LEMP. WooCommerce с фильтрами товаров, личные кабинеты, API-сервисы — везде, где запросы уникальны и кеш не помогает, LEMP обрабатывает такую нагрузку в 3–4 раза быстрее, чем OpenLiteSpeed без кеша. При экстремальных нагрузках он замедляется, но не ломается, хотя tail latency доходит до 9 секунд, но соединения не сбрасываются.

Второе преимущество LEMP: он работает из коробки. OpenLiteSpeed с дефолтной конфигурацией получил LSAPI deadlock при первых же параллельных запросах (99% перцентиль — 60 секунд). После настройки (50 PHP workers вместо 10, правильные таймауты) проблема ушла, но это требует времени и понимания. LEMP просто работает.

Если 70%+ контента кешируется — ставьте OpenLiteSpeed, экономия ресурсов и прирост скорости того стоят. Если половина запросов уникальна или нужна гарантированная стабильность под пиковыми нагрузками — берите LEMP.

Маркетплейс приложений HOSTKEY
Арендуй сервер с предустановленным WordPress с OpenLiteSpeed или LEMP.

Посмотреть