Как Яндекс.Дзен, плагин кэширования для WordPress и хостинг повысили мое давление

    image

    Это статья, скорее, из серии «хозяйке на заметку». Ну и еще немного о личных переживаниях и раздолбайстве.

    Если вам приходится сталкиваться с сайтами на 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 по МСК». Самое интересное, что на почте, как ни искали, никаких сообщений от хостера об этих работах мы так и не нашли. Тикет при этом был, минимум, суточной давности. До этого подобные сообщения приходили на почту, а в тикеты службы поддержки (да и в сам кабинет хостера) никто без особой надобности обычно вообще не смотрит. Поэтому произошедшее стало большой неожиданностью. После чего мы поругали за глаза хостера, посмеялись, подождали пока все не заработает и пошли спать.

    Вот такая история.
    • +17
    • 7,3k
    • 5
    Поддержать автора
    Поделиться публикацией

    Похожие публикации

    Комментарии 5

    • НЛО прилетело и опубликовало эту надпись здесь
        +1
        Я встречал описание подобной ситуации раньше. В рекомендации весьма специфичное предложение от 2010-го (!) года настроить в Google Analytics распознавание "#" вместо "?" в URL'е, добавив pageTracker._setAllowAnchor(true); перед _trackPageview в код счётчика.

        Т.е. в итоге перейти на использование, например, вот такой конструкции:
        https://xn----7sbbfbnfa0a2audfacc2cat8e9f.xn--p1ai/#utm_source=habr.com&utm_medium=urlwithhash

        вместо привычного
        https://xn----7sbbfbnfa0a2audfacc2cat8e9f.xn--p1ai/?utm_source=habr.com&utm_medium=standardurl

        Собственно, в итоге задача остаётся решённой не полностью — какие-то системы могут не поддерживать такой формат, а что делать с УРЛами, у которых «отрастает хвост» не по вине владельца сайта (как в статье), в рамках работы плагина вообще неясно.
        0
        How should I best use the utm_source tracking tools in Google Analytics with this plugin?
        That tracking adds a query string to each url linked from various sources like Twitter and feedreaders. Unfortunately it stops pages being supercached. See Joost’s comment here for how to turn it into an anchor tag which can be supercached.
          0
          Последние два дня ситуация с небывалым наплывом посетителей с Дзена (журналисты сделали виральный заголовок к одной статье). Увеличение трафика в 6 раз (с 10k до 60k просмотров). Кеширующий плагин WP Rocket. Вывозит нормально, но бывают затыки, когда проходит время жизни кеша, Load average увеличивается с 0.5 до 7 минут на 5, потом все успокаивается, и снова 0.5.
            0
            С ходу родилась лишь мысль — каждый раз парсить URL и игнорировать полностью весь GET для плагина.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое