Это статья, скорее, из серии «хозяйке на заметку». Ну и еще немного о личных переживаниях и раздолбайстве.
Если вам приходится сталкиваться с сайтами на 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
Т.е. Яндекс.Дзен добавляет свою utm-метку к адресу. Поскольку сервер уже окончательно лежит и отдает мне только 500, то проверить теорию о том, что страницы с таким «довеском» почему-то не кэшируются, я толком не могу. Поэтому рождается очередной «костыль» (впоследствии был заменен): в .htaccess добавляется редирект, который преобразует запрос с utm-метками в запрос без них до того, как в дело вступит WordPress и все его могучие плагины. Машина перезагружается и, вуаля, все работает: сайт быстро загружается, сервер тихо шуршит на пониженных оборотах. Как ничего и не было.
Тут я расслабился и полез спокойно смотреть настройки плагина кэширования. В первую очередь — галочку «Не кэшировать страницы с параметрами GET», которая там есть. Все нормально, она не стоит. Плюс, как показал эксперимент, плагин отлично справляется с кэшированием запросов с любым набором произвольных параметров. Если это не utm-метки (на самом деле, я срезал редиректом только запросы определенного вида, а не все, где есть utm-метки).
Вот тут я внимательнее (с помощью CTRL+F) пригляделся к странице плагина. И нашел там в FAQ славный пункт “How should I best use the utm_source tracking tools in Google Analytics with this plugin?”. Понятно, что при первом беглом осмотре я его благополучно проигнорировал: вроде бы ничего общего с проблемой. При этом, кстати, он не то чтобы очень содержательный и не предлагает какой-то конкретный путь решения.
Единственный возможно полезный вывод в статье: если у вас сайт на WP с плагином WP Super Cache, то проверьте, что он делает (или не делает), если ему на вход подать запрос со параметрами «?utm_referrer=https:%2F%2Fzen.yandex.com» и т.п. Я не уверен, что при установке этого плагина все так уж внимательно читают его FAQ. Конкретная реализация, судя по всему, остаются за владельцами сайта: когда я в последний раз смотрел на обновление этого плагина, никаких изменений по поводу его странной реакции на utm-метки я не увидел.
Но история была бы неполной (и я не стал бы ее рассказывать), если бы не случилось очередного подтверждения закона Мерфи. Пока мы мирно переписывались со владельцем сайта и наблюдали, как сайт спокойно работает около часа … сайт упал. Неожиданно и окончательно. Нет доступа к панели управления сервером, не работает FTP, SSH и все прочее. Ничего не работает. Если до этого мое давление было лишь слегка поднято решением задачи, которую подкинули Я.Дзен и плагин кэширования (ведь это отдельное удовольствие — быстро понять и починить что-то в условиях легкой нервотрепки), то тут со мной приключилась целая мини-паническая атака. И только смутное ощущение того, что парой строчек в .htaccess невозможно убить всё через час после внесения этих строчек, не дало перерасти «мини» в нечто более полноценное. В общем, после пары минут обмена удивленными сообщениями мы полезли в личный кабинет хостинг-провайдера у которого живет сервер. И там в тикетах мы нашли предупреждение о «технических работах с X по Y по МСК». Самое интересное, что на почте, как ни искали, никаких сообщений от хостера об этих работах мы так и не нашли. Тикет при этом был, минимум, суточной давности. До этого подобные сообщения приходили на почту, а в тикеты службы поддержки (да и в сам кабинет хостера) никто без особой надобности обычно вообще не смотрит. Поэтому произошедшее стало большой неожиданностью. После чего мы поругали за глаза хостера, посмеялись, подождали пока все не заработает и пошли спать.
Вот такая история.
