Это статья, скорее, из серии «хозяйке на заметку». Ну и еще немного о личных переживаниях и раздолбайстве.
Если вам приходится сталкиваться с сайтами на WordPress, на которых установлен плагин кэширования WP Super Cache, то статья может быть для вас небесполезна. В остальном, это просто небольшая история.
Вкратце, начало истории таково: жил был сайт. Тематический информационно-новостной. Сделанный неведомым мастером на CMS WordPress. И сделанный ровно так, как того позволяли в тот момент средства его владельца. Со временем сайт набирал популярность, количество посетителей росло. Сам сайт «зарабатывал» на рекламе. Т.е. чем больше посетителей — тем лучше. В какой-то момент, при пиковых нагрузках, сайт начал сдавать: страницы загружались медленно и все такое. Но, конечно, пока петух не клюнул, никто особо не шевелился. Петух появился в момент, когда сайт должен был освещать некоторое привлекающее внимание публики событие. Посетители набежали, сайт лег, а все предполагаемые доходы таяли на глазах. В силу обстоятельств в качестве реаниматора пришлось выступать мне. Об этом я написал тогда статью. Мое решение было жутковатым (не повторяйте), но главная цель была выполнена — мечты были спасены. В основном.
Разумеется, никто не был заинтересован в повторении подобной ситуации и над сайтом поработали. В первую очередь — выяснили причины падения и высокой нагрузки на сервер. Они были банальны: отсутствие на сайте кэширования как такого и скверно реализованный механизм учета и показа количества просмотров статей. Последний сам по себе создавал приличную нагрузку: при каждом запросе страницы статьи он брал из базы данных количество просмотров этой статьи, выводил его, а затем прибавлял единицу и записывал обратно в БД. При этом для хранения использовалась таблица wp_postmeta с метаданными (так это, кажется, называется в WP). В которой хранилась масса совершенно не относящейся к учету просмотров информации и которая была весьма велика.
Проблему кэширования решили просто: в спокойной обстановке нормально установили плагин WP Super Cache. Что, многие, если я правильно помню, советовали мне сделать вместо жутковатого костыля, который я соорудил, в комментариях к той моей статье. Честно говоря, я и тогда и сейчас плохо ориентировался в экосистеме WordPress и поэтому и появился тот костыль. Плагин кэширования ставили и настраивали уже знающие люди и он хорошо встал прямо «из коробки». Таким образом была решена проблема кэширования. Почему был выбран именно этот плагин — я точно не знаю. Насколько я понимаю, это один из самых популярных плагинов такого типа для WP.
С учетом просмотров поступили несколько иначе. Понятно, что от изначального механизма нужно было отказаться. От самого учета просмотров отказываться не хотелось: на него, как минимум, был завязан показ блоков вроде «самые популярные статьи за неделю». Все плагины для учета просмотров, даже если они и «дружили» с плагином кэширования, оказались весьма прожорливыми и, чаще всего, реализовывали тот же механизм с записью и извлечением данных из wp_postmeta. Для небольшого сайта это вполне подходит. Для сайта с достаточно солидными пиковыми показателями посещаемости — уже нет: слишком прожорливо для такой небольшой функции. Тут как нельзя кстати подвернулся оплаченный на годы вперед и неиспользуемый хостинг. Самый простой и дешевый. На него и свалили обязанности по хранению, учету и отдаче данных о просмотрах. Все асинхронное, т.е. даже если он упадет, то основной сайт продолжит спокойно показывать статьи, рекламу и все, что должен показывать. Оперативное хранение данных о просмотрах возложили на Redis, а долговременное — на MySQL. Так оно и крутится, есть особо не просит и выедает 1-2% от максимально разрешенной нагрузки на том хостинге.
И вот, проходит довольно продолжительное время. Опять ночь и опять старая история. На сайт идет довольно мощный трафик и сайт начинает падать. И опять я оказываюсь единственным бодрствующим условным специалистом в округе. Я, конечно, удивлен повторению событий. Первая мысль — кто-то случайно отключил кэширование. Но нет, в исходном коде страницы сайта, который отдает мне падающий сервер я вижу признаки работы плагина кэширования. Все должно быть ok. Но в панели управления сервером я вижу, что оперативной памяти не осталось, количество запросов к БД неимоверное и все плохо. Первым делом, я открываю страницу с описанием плагина, быстро пробегаю ее глазами, ничего не обнаруживаю и оставляю это занятие. Следующий шаг — посмотреть статистику. Я вижу, что основной поток трафика льется на сайт с Яндекс.Дзен. И запрос, который приводит пользователя на сайт, выглядит так:
https://example.com?utm_referrer=https:%2F%2Fzen.yandex.com
К сожалению, не доступен сервер mySQL