Снижаем нагрузку на сайт с помощью Cloudflare

О Cloudflare я узнал когда зашел на один сайт и увидел вместо ожидаемой страницы я увидел вот такую вот картину:

Увидев новое слово, я тут же решил загуглить, я бы не сказал что информации по этому сервису изобилие, но её вполне достаточно для того, чтобы понять что такое Cloudflare. Правда я на тот момент плохо понимал как он может быть полезен именно мне, поскольку я не обладаю серьезными сайтами, которые нуждаются в снижении нагрузки. Но время шло и в какой-то момент мой сайт начал создавать нагрузку на хостинг, причем если раньше это были разовые пики, то в этот раз превышения были каждодневными и только благодаря терпению хостера мне не заблокировали аккаунт. Нагрузка не падала больше недели и я понял что надо что-то делать. Настройка WP Super Cache не спасала и я вспомнив про Cloudflare пошел добавлять туда сайт. Процесс добавления сайта подробно описан в этой статье.

Но простое добавление ситуацию никак не спасло, нагрузка на хостинг никак не изменилась. Я решил изучить функционал Cloudflare чуть по подробнее. Оказалось с помощью Page rules можно управлять кешированием, а именно, задавать время хранения страниц и файлов на серверах Cloudflare. Иными словами мы можем указать Cloudflare что и сколько времени хранить. При желании конечно можно посмотреть что именно создает нагрузку и кешировать именно то, но я решил не заморачиваться и создал вот такое правило на вкладке «Page rules»:

Тем самым я указал что нужно кешировать весь сайт и добавил три параметра:

  • Browser Cache TTL — указывает браузеру сколько времени хранить полученные файлы. Я ставлю один день, поскольку браузер хранит даже страницы.
  • Cache Level — тут мы указываем что Cloudflare должен кешировать. Я выбрал кешировать все.
  • Edge Cache TTL — тут указываем сколько времени живет кеш на сервере Cloudflare.

После этих настроек на следующий день я увидел долгожданное падение нагрузки:

Пустой столбик в самом конце графика — это уровень нагрузки, по сравнению с предыдущими значениями он кажется ниже плинтуса. Но радость была не долгой. Неладное я почуял когда зашел в админку и увидел комментарий, который отправил в папку «Спам». Тогда я понял что страница сохранилась в кеше браузера и тут же я понял что эта же страница хранится и на Cloudflare. Открыв ссылку на админку в анонимной вкладке я увидел страницу админки. Конечно особо страшного в этом ничего нет, поскольку ссылки там «устаревшие» и на эти страницы можно только смотреть, но все равно было очень неприятно. В большей степени это мешало тем, что это не позволяло полноценно управлять сайтом, поскольку страницы админки загружались из кеша и было не понятно почему плагины не обновляются, спам не удаляется и т.д.

Тогда я понял что для админки необходимо кеш отключать, но, к сожалению, у меня ничего не получилось. Настройки Cloudflare не такие гибкие, как хотелось бы, ну или я ещё плохо понимаю как он работает и моих познаний не достаточно чтобы виртуозно манипулировать его настройками. Первая мысль поразила своей простотой. Поскольку трафик на сайт идет через сервера Cloudflare, то отключить кеширование для себя можно направив трафик напрямую на наш сервер с помощью файла hosts, указав там ip сервера, на котором работает наш сайт, и соответственно домен. Эта схема работает если у сайта нет SSL или он нормальный, а вот с SSL от Cloudflare такая схема попросту не работает. Если с моим сайтом все хорошо, ибо пока ещё купленный сертификат стоит, то с другими сайтами возникли проблемы из-за вечно всплывающего окошка:

Целый день я ломал голову по поводу того, как сделать для себя «черный» вход, чтобы можно было спокойно управлять сайтом не включая «Developer Mode», который на время отключает работу Cloudflare и обращаясь к сайту мы получаем все от него, а не из кеша Cloudflare. Этот режим автоматически отключается через 3 часа и велика вероятность того, что страницы админки попадут в кеш если мы «проспим» отключение «Developer Mode». Я в принципе отмел этот вариант сразу же, поскольку статьи я пишу прямо в редакторе сайта, и бывает страница админки открыта по нескольку дней.

И тут я вспомнил про тестовый домен, который есть у каждого сайта на SpaceWeb. Выдается он для того, чтобы была возможность работать с будущим сайтом без регистрации домена для него. Но тестовый домен продолжает существовать и после того, как домен был зарегистрирован. По сути это домен аж четвертого уровня типа site.ru.swtest.ru, где site.ru — наш домен. К сожалению и тут не обошлось без проблем.

Основная проблема заключается в том, что при добавлении в статью картинки, она не будет отображаться на реальном домене, поскольку в её адресе будет фигурировать тестовый домен и если на реальном домене будет SSL, то картинка будет заблокирована. По причине того, что для исключения редиректа на реальный адрес сайта, нам приходится прибегать к небольшой хитрости и осуществлять подмену путем создания двух констант WP_HOME и WP_SITEURL, добавляя туда наш тестовый домен, то само собой в пути к картинкам, файлам и ссылкам добавляется именно тестовый домен. Тоже самое происходит при редактировании темы, если загружаются изображения или в меню добавляются ссылки, там также присутствуют абсолютные адреса. Проблема, но она легко решается, ведь у WordPres’а есть API с помощью которого можно отслеживать места, куда могут попасть ссылки с тестовым доменом.

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

Оценка статьи

Полная фигняУзнал немного новогоНормальная статьяХорошая статьяСупер! (2 оценок, среднее: 5,00 из 5)
Загрузка...

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Подпишитесь на рассылку и получайте новые статьи на почту