WordPress & HighLoad — особенности работы на высоких нагрузках

Продолжаем развенчивать мифы, шаблоны и стереотипы относительно WordPress. В прошлый раз разбирались WordPress — просто это или нет. В этот раз поговорим о больших нагрузках.

Статья была написана в 2017 году. С тех пор много воды утекло и автор успел поменять свое мнение 10 раз и переобуться. Потому она оставлена как история. Но не стоит тут верить всему что написано.

цитата 2024, автор тот же

Опять же часто встречаются комментарии все тех же «знающих программистов» о том что WordPress это вообще тормоза и для больших нагрузкой оно не катит. И большинство начинают верить в эти утверждения, птм что нечего противопоставить.

Те кто плотно работает с highload как правило не знают ничего про WordPress, а те кто работают с WordPress зачастую в глаза не видели highload. Конечно есть куча ресурсов WP с highload (при желании можно найти), а значит есть и те кто это понимают, но они как правило уже давно переросли возраст холиваров и в комментариях их мнение сложно увидеть.

Давайте попробуем затронуть и разобрать некоторые идеи.

JAMStack как серебряная пуля

В целом есть сегодня мир JAMStack и если подключить это к WordPress. То с ходу получается решить 99% проблем и получить максимально возможную скорость.

С одной стороны можно взять гибкость WordPress и его 100500 плагинов, которые позволяют экономить годы и миллионы долларов.

С другой стороны берем что то типа NextJS с ISR и получаем максимально возможную скорость которая сегодня только возможна в мире веб.

Пример тут.

Проблема С10k

Одна из первых проблем с которой знакомятся те кто поймал highload это проблема «10000 подключений в секунду». Известная тема, на которую есть куча статей, включая одну в википедии.

Зачастую в этой проблеме нет «имбы» и какой то «серебряной пули». Каждый ищет метод решения проблемы с учетом своих ресурсов, конфигурации и опыта.

Надо лишь понимать что в большинстве случаев нужно искать решение в направлении асинхронных обработок запросов, построение систем очередей и конечно же разных типов кластеризации.

На сколько мне известно ни один сервер приложений не сможет выдержать эту проблему за сколько нибудь разумные затраты. Потом обычно это решается средствами nginx через проксирование к кешу ранее выполненных запросов. Кеш как правило лежит в хранилище (файлы, memcached, redis …). Либо в редких ситуациях где кеш не подходит по каким-то веским причинам сразу переходят в балансировку нагрузок через кластера веб приложений.

Другими словами если все 10 000 запросов в секунду долетят до php, python или ruby — то обычно это будет означать коллапс системы. Еще раньше умрет БД, особенно если это SQL-запросы.

Nginx в отличие от Apache — обрабатывает запросы через асинхронный цикл. Именно эта способность позволяет ему проще пережевывать большое число запросов и эффективней использовать ресурсы сервера. Но только если эти запросы не дойдут до php. Будут завернуты к файлам, к кешу memcached или redis или к веб кластерам.

Условно говоря 80% запросов у highload ресурсах обрабатываются средствами nginx & memcached. Не трогая php, sql & WordPress.

В мире WP один из лучших плагинов кеширования страниц в memcached это Batcache. Но есть решения для файлов и redis. А при желании можно написать свой плагин.

NoSQL

Далее как правило упираемся в нагрузки БД и минусы SQL. Это не значит что надо выстрелить себе в голову и переписать весь сайт на MongoDB как полагают многие программисты. Как правило надо понимать принцип узких горлышек и работать с ними. Чаще всего на крупных ресурсах узким горлышком становится система поиска. Будь то какой то большой новостной портал или магазин с большим количеством товаров и фасетным поиском по различным атрибутам. В этом случае делается поисковый индекс на какой то NoSQL платформе. Сегодня чаще всего выбор падает на Algolia или Elastic.

Таким образом поиск становится мгновенным и не дает нагрузку на вашу БД. Вся нагрузка падает на NoSQL хранилище.

EAV & SQL

Многие критикуют механику EAV (Entity Attribute Value) за ее метаполя и медленные запросы по ним. Обычно это означает что программисты которые жалуются на эту проблему просто прикрывают свою плохую сообразительность и способность к мышлению. Цель EAV — упростить разработку для большинства задач. Но это не универсальный инструмент на все случаи жизни.

Если мы начинаем работать с большими данными то логично что сначала это может потребовать сделать отдельные таблицы в БД, перейти на SQL через $wpdb. Тут мы можем пробить определенный предел размера данных, но пожертвуем простотой и гибкостью.

В какой то момент системы упираются в пределы SQL. Данные придется выводить на отдельные сервера или даже в NoSQL. Это еще сильнее убивает простоту и гибкость, но зато дает масштабирование.

Нет идеальных решений. Мы всегда жертвуем размерами чтобы получить простоту и защиту от энтропии, либо жертвуем простотой в угоду масштаба. Опять же все решения есть под WordPress если включать голову и поискать.

Балансировка запросов

Вот мы убрали 80% запросов на nginx & memcached, а тяжелые поисковые запросы завернули на NoSQL. Обычно этой связки хватает с лихвой даже очень крупным ресурсам. Но рано или поздно с ростом системы те 20% запросов которые мы обязаны обрабатывать силами сервера приложений и БД начинают создавать проблемы.

Наступает момент когда пора делать балансировщики нагрузки и распределять запросы между множеством веб серверов. Количество балансировщиков и веб серверов зависит от размера приложения. Иногда хватает 3-4 сервера. В мире WordPress самый крупный ресурс это wordpress.com и там на сколько мне известно таких серверов сотни. Весь кластер около 2000 серверов. Включая множество серверов БД, CDN …

Шардинг и репликация БД

Еще одно узкое горлышко с которым рано или поздно встречается любой нагруженный ресурс это размер данных. БД перестает вмещаться на 1 сервер. Приходится распределять разные таблицы на разные сервера. В мире WordPress для этих целей есть плагин HyperDB и API которое позволяет это делать. Но пока что из известных систем эта проблема встречается только на мультисайтах. Когда есть некое облако которое хранит множество разных сайтов и приложений.

Репликация БД у MySQL более чем достойная. Хоть и не идеальная. Многие под влиянием хайпа предпочитают PostgreSQL. Единицы кому это реально нужно типа Uber сначала перешли на PostgreSQL, а потом вернулись на MySQL. Кому то PostgreSQL действительно подходит больше. В том мире также идут холивары кто круче. В нашем случае никто не мешает нам подключить даже PostgreSQL если того требует ситуация и характер хранимых данных. Но такое сложно себе представить.

Обычно если встречается какой-то блок с большим потоком данных, то там основная ставка идет на СУБД. И у таких систем простой интерфейс пользователя, либо он вообще отсутствует. А основная работа идет через API. WordPress в таких системах взаимодействует с такими данными посредством API.

Очереди

Еще одна частая проблема это необходимость работать с каким то потоком задач которые нельзя выполнять по запросам. В этом случае ставится нечто типа RabbitMQ и задачи обрабатываются в рамках очередей.

Переход в микросервисы

Ну и последний пункт. В каких то ситуациях приходится покупать готовые или делать свои микросервисы. Все крупные системы рано или поздно доходят до этого момент. В качестве примера уже выше был описан вариант с Algolia. Когда под узкое горлышко сложных поисковых запросов подключается внешнее приложение для работы с ними.

Еще один пример это Mandrill и масштабирование SMTP отправки писем через REST API. Также есть готовые плагины для WP.

Возможно появится какое то еще узкое горлышко. В 99% случаев это проблема которую уже кто то решил и есть какое то готовое решение под WP.

Но даже если появится нечто уникальное, то можно написать свой микросервис под узкое горлышко своими силами. На базе nodejs, golang или symfony или каком то еще фреймворке/платформе которые хорошо могут пережевывать большие потоки запросов, но плохо справляется с энтропией сложного функционала.

Итого

В 100% случаев которые встречались автору, когда кто-то утверждается нечто типа «вот мы уперлись в тормоза WordPress» если покопать то выясняется что реальная причина в тормозах головного мозга тех кто ведет разработку. В большинстве случаев достаточно просто заменить какой-то кривой компонент или ужасный алгоритм, написать более оптимальный код.

Сильно реже встречаются реальные «взрослые» узкие горлышки и элементарное не знание как решаются проблему узких горлышек в больших системах. А они решаются плюс минус одинаково вне зависимости от основной платформы. У вас может быть WordPress, Django, RoR или NodeJS — но рано или поздно вы упретесь в какие то узкие горлышки. И решения будут примерно одинаковыми.

Автор часто встречал ситуации когда программисты в силу слабости ума бросались в крайности. На хайпе вокруг NoSQL бросались писать CMS или целые сайты на базе MongoDB. На хайпе вокруг NodeJS бросались писать на нем Интернет-магазины. Надо ли говорить что все эти проекты умерли или живут на грани рентабельности? Просто птм что у них затраты в 10-100 раз выше от возможных. Они не жизнеспособны изначально. Но слепой фанатизм и юношеский максимализм не позволяет это понять. У любой технологии есть плюсы и минусы. Не бывает серебряных пуль.

Всегда стоит брать под задачу то что является лучшим решением. Например для сайтов и управления контентом лучшим решением является WordPress (№1 в мире, более 30% рынка и наличие множества крупных нагруженных ресурсов тому подтверждение). Конечно с ростом придут проблемы узких горлышек. Надо решать проблемы по мере их поступления. В 99% случаев под каждое узкое горлышко уже есть какое то решение. Надо лишь включить голову и найти его.