Всем привет!!!
В этой статье я постараюсь рассказать про плагин W3 Total Cache для кеширования WordPress и как его настроить для сайта блога.
Введение
Это мой рассказ про свой опыт сайта блога на WordPress. Делаю я это в первую очередь для себя, что бы в будущем не забыть про это и было где получить воспоминания. Быть администратором сайта новый и очень интересный опыт для меня. Раньше сайтов с такой нагрузкой у меня не было и честно сказать понять как быть в таких случаях совсем не просто. В интернете просто нет такой информации.
Я создавал сайт у себя дома на домашнем сервере и не планировал, что этот сайт будет пользоваться такой популярностью. Более того, я прям сказать не хотел этого. Но время шло, я развивался сам и вместе со мной развивался сайт. Через несколько лет я заметил, что интернет дома работает не очень хорошо, при этом нагрузки на этот самый интернет не было большой. Так же после некоторых проблем с электричеством и интернетом я все же задумался о переносе сайта на хостинг. После преодоления порога в 3000 просмотров в сутки я все же решился перенести сайт на хостинг.
Перенос сайта не занял долгое время, за пару часов я это реализовал и наслаждался свободой. Теперь я мог спокойно выключать сервер, проводить пылевую уборку и если отключают интернет или электричество, то это меня уже совсем не волновало. Но проблема пришла с той стороны откуда я не ожидал.
Оказывается, помимо размера сайта нужно еще учитывать разные параметры: Нагрузку на процессор, нагрузку на базу данных и количество файлов. И тут меня ожидал полный провал. Я взял хостинг с максимальной нагрузкой на процессор 6%, а нагрузка сайта составляла 8-10%. Мой хостер уже на третий день прислал уведомление, о блокировке сайта, если я не поменяю тариф в течении суток или не снижу нагрузку на процессор.
Купить более дорогой тариф для хостинга не проблема, но это же деньги, а они не бесконечные. Поэтому я стал искать другие варианты. На самом деле есть только один другой вариант – это кеширование сайта. Сайт написан на PHP, а браузеры получают HTML страницу. Это происходит после обработки кода PHP в HTML. Кеширование работает следующим образом. Страницы сайта сохраняются сразу в HTML формате и таким образом нагрузка на процессор существенно падает.
Кеширование в WordPress — это важная практика, которая помогает улучшить производительность сайта. Вот несколько основных причин, почему кеширование необходимо:
- Ускорение загрузки страниц: Кеширование сохраняет статические версии страниц, что позволяет серверу быстрее их предоставлять пользователям без необходимости повторной обработки каждого запроса.
- Снижение нагрузки на сервер: Когда страницы кэшируются, серверу не нужно обрабатывать каждый запрос к базе данных и выполнять PHP-код, что уменьшает нагрузку и позволяет обрабатывать большее количество посетителей одновременно.
- Улучшение пользовательского опыта: Быстрая загрузка страниц положительно сказывается на пользовательском опыте, что может привести к снижению показателя отказов и увеличению времени, проведенного на сайте.
- Оптимизация SEO: Поисковые системы, такие как Google, учитывают скорость загрузки страниц при ранжировании сайтов. Быстрые сайты имеют больше шансов занять более высокие позиции в результатах поиска.
- Экономия ресурсов хостинга: Особенно на совместных хостингах, где ресурсы ограничены, кеширование помогает избежать превышения лимитов и снижает вероятность сбоев.
- Снижение времени отклика: Кеширование может значительно сократить время отклика сервера, что также положительно влияет на общую производительность сайта.
В WordPress существует множество плагинов для кеширования, таких как W3 Total Cache, WP Super Cache и другие, которые позволяют легко настроить кеширование и оптимизировать сайт.
Мой выбор пал на плагин W3 Total Cache тем более его много кто рекомендовал. В интернете есть очень много статей как настроить этот плагин. Самая хорошая статья на хабре, но я решил, что в начале своего пути пойду по другим статьям в интернете. Это и была моя большая ошибка. Нужно было слушать статью на хабре, хотя и она не лишена недостатков, о которых я расскажу далее. Но если бы я поступил правильно, я бы не узнал много чего интересного, что и будет рассказано далее. С другой стороны, в той статье на хабре не было конкретики, под что настраивался плагин кеширования. В результате могу сказать, что для сайта блога не совсем подходит та замечательная статья на хабре, а так же для новостного сайта. Статья на хабре подойдет для небольших сайтов с небольшим количеством статей, которые не растут как снежный ком как любой живой сайте блога.
Настройка
Давайте я расскажу как настроить плагин W3 Total Cache, что бы не нарваться на проблемы, с которыми столкнулся я.
Открываем плагин W3 Total Cache и переходим в витрину функций. Нужно найти Мастер руководства по установке и запустить его. Этот мастер прогонит вас по всем его настройкам и наглядно покажет как лучше для вашего сайта, какие модули включить, а какие лучше не трогать. Так подумал я, когда первый раз его настраивал.
Мастер предлагает включить все и сразу: кеш страниц, кеш OpCode, кеш базы данных, кеш объектов и кеш браузера. И по началу я это все включил. Меня ждало огромное разочарование. Да нагрузка на сайт упала, но он начал расти в размерах. В сутки прибавлялось по 2-5ГБ. Сайт с 10ГБ стал весить 20ГБ за очень короткое время.
После поиска причины я выяснил, что место занимает кеш объектов. При настройке кеша объектов я выбрал кешировать на диск. Обусловливал я это еще на своем домашнем сервере тем, что ОЗУ у меня не много, зато у меня быстрые SSD M2 диски и на тот момент мне казалось это очень правильное решение. Как же я ошибался. Поэтому кеш объектов лучше вообще не включать в плагине. Предоставьте это хостингу.
Если вы собираетесь включать кеш объектов и базы данных, то нивкоем случаи не включайте их на диск. Нужно выбрать оперативную память. При использовании диска этими кешами образуется огромное количество файлов, которые не удаляются плагином, файлов становится миллионы и как правило хостинг отключит ваш сайт. Опять же учтите, что включение данных кешей в оперативну память, приведет к ее быстрому заполнению и как правило опять к блокеровке хостингом вашего сайта.
Что же тогда включать, а что нет? Давайте по пунктам.
- Кеш страниц – это то, что нужно включить обязательно. Можно сказать ради этой функции все затевалось. Далее я расскажу подробнее про эту настройку.
- если ваш хостинг поддерживает Memcached, то используйте его при настройке кеша страниц. Вот тут инструкция от reg.ru. На других хостингах уточняйте, не все это поддерживают и не на всех тарифах.
- Кеш браузера – это то же включаем обязательно. Когда в браузере будет кеш страницы, то нагрузки на сервер вообще не будет никакой в теории.
- Кеш OpCode – выключить нельзя, не знаю почему.
- Все остальное кеширование отключаем. Например, зачем кешировать базу данных, когда уже есть кешированная страница и запросов в эту самую базу данных нет.
Тонкие настройки кеша страниц.
На хабе этому так же уделено много внимания, как и на других сайтах в интернете. Как правило, везде рекомендуют делать одно и тоже, ну плюс минус. Например, везде рекомендуют включать автозаполнение кеша. На хабре даже есть расчеты сколько страниц кешировать за раз. Вот только как показала моя практика для сайта блога с 500 и более страницами это выстрел в ногу. Просто все преследуют разные цели видимо.
Когда включено авто заполнение кеша, сервер будет заниматься только этим заполнением кеша. Поставите много страниц за раз, начнутся перегрузки сервера и как следствие блокировка сайта. Поставите мало, сервер будет постоянно занят вашим сайтом, начнет забиваться cron и как итог куча мусора и медленный сайт, а в добавок повышенная нагрузка на процессор и привет деньгам на новый более дорогой тариф хостинга. Поэтому автозаполнение кеша не включаем, кеш будет заполняться сам по мере посещения пользователями страниц сайта.
В то же время я установил предварительная загрузка кеша при публикации и при обновлении. Последнее поможет обновить кеш при редактировании статьи, а такое возможно.
Я пошел другим путем, не тем что предлагают в интернете и на хабре. Включил кеш страниц в режиме Disk Enhanced т.к. этот режим самый быстрый по заявлению мастера первоначальной настройки и другим статьям в интернете.
Затем я перешел в расширенные настройки и тут надо отметить. Я не буду рассказывать все параметры, а только те, которые поменял. Т.е. параметры по умолчанию, которых очень много я не буду упоминать сейчас.
Первым делом я отключил кеширование для группы администраторов и включил кеширование для авторизованных пользователей. Дело в том, что на сайте можно писать комментарии и значит можно авторизоваться, а следовательно я не хочу что бы авторизованные пользователи повышали нагрузку на сервер. А сам я должен всегда видеть любые изменения сразу, поэтому для своей группы я отключил кеширование.
Ниже есть параметры хранения кеша. Хотелось бы установить максимальное время жизни кеша бесконечно, но к сожалению эта опция платная. Поэтому я указал тут неделя в секундах 604 800, а можно и месяц, но месяц это максимум. Дело в том, что страницы они не изменяются годами и соответственно можно хранить их кеш вечно. Что бы была возможность включить вечное хранение кеша, нужно купить PRO версию плагина W3 Total Cache.
Интервал сбора мусора я установил в 1 час. Раз в час удалить старые ненужные файлы не вызывает большой нагрузки на сервер, хотя можно установить и раз в сутки. Если делать это очень редко, то сервер может не успеть почистить мусор за 5 минут, а это максимальное время работы скрипта на сервере.
Спустившись ниже нужно указать страницы, которые не следует кешировать: blog, category, page, tag. Эти страницы я исключил не просто так. Самая большая проблема с ними это их количество. Категории и метки генерят очень много кеша и на хостинге может просто не хватить ресурсов под такое количество файлов. В добавок, т.к. я не очищаю кеш как можно долго, то после новой публикации она может не попасть в эти кешированные страницы. Поэтому я их исключил из кеширования. Все же люди чаще ходят на конкретные страницы, чем щелкают по меткам и категориям.
Доработка плагина
Когда я настроил все вышесказанное и наблюдал за работай кеша, все было превосходно ровно до момента создания новой статьи. Дело в том, что статья готовится не один день, иногда даже неделю и более и постоянно редактируется. При подготовки статьи я сохраняю ее в черновик. Проблема заключается в том, что при каждом сохранении черновика кеш сбрасывается. В общем происходит очистка кеша и соответственно нагрузка на сайт возрастает моментально.
Какие бы я не менял настройки в плагине W3 Total Cache ничего не помогало. Тогда единственным выходом стало обращение в тех.поддержку этого плагина. Я не ожидал уже результата, когда один из разработчиков предложил такое решение. В чем суть проблемы? Оказывается при сохранении статьи в черновик другой плагин отдает команду очистки кеша. А решение просто не давать очистить кеш без нажатия кнопки очистки этого самого кеша.
К сожалению разработчки W3 Total Cache не рассказали как они видят решение проблемы, а дали просто сырой код. Поэтому проблему все же пришлось решать самому. На самом деле все просто, нужно создать плагин с этим кодом:
- Войдите на ваш сервер через FTP или используйте файловый менеджер в панели управления хостинга.
- Перейдите в папку wp-content/plugins.
- Создайте новую папку, например, custom-w3tc-fixes.
- Внутри этой папки создайте файл с именем custom-w3tc-fixes.php.
- Откройте этот файл и добавьте следующий код:
<?php
/*
Plugin Name: Custom W3TC Fixes
Description: Prevents unnecessary cache flushing in W3 Total Cache.
Version: 1.0
Author: Alexandr Linux
*/
add_filter( 'w3tc_preflush_posts',
function( $do_flush, $extras ) {
if ( isset( $extras['ui_action'] ) && $extras['ui_action'] == 'flush_button' ) {
return $do_flush;
}
return false;
},
99999, 2 );
add_filter( 'w3tc_preflush_all',
function( $do_flush, $extras ) {
if ( isset( $extras['ui_action'] ) && $extras['ui_action'] == 'flush_button' ) {
return $do_flush;
}
return false;
},
99999, 2 );- Сохраните файл и вернитесь в панель управления WordPress.
- Перейдите в раздел Плагины и активируйте ваш новый плагин “Custom W3TC Fixes”.
После этого необходимый код будет работать и предотвращать лишние срабатывания w3tc_flush_all и w3tc_flush_posts, за исключением случаев, когда действие инициируется через интерфейс пользователем.
И действительно, пока я писал эту статью и сохранял ее черновик, кеш ни разу не очистился. Результат на лицо.
Как вообще узнать сколько кеша и старый он или актуальный? Для этого нужно перейти в папку с кешем и с помощью команды find с конвеером wc подсчитать количество файлов кеша и очищенного и устаревшего. В моем случаи на примерно 500 статей получилось 1103 файлов кеша. Из них 166 устаревших, а 934 актуальных на данный момент.
$ cd wp-content/cache/page_enhanced/bafista.ru/
$ find ./ -maxdepth 20 -type f | wc
1103 1103 80165
$ find ./ -maxdepth 20 -type f | grep old | wc
166 166 12435
$ find ./ -maxdepth 20 -type f | grep -v old | wc
934 934 67487Если вы спросите почему больше 1000, то не из-за того что страниц больше 500, а из-за того что в некоторых страницах есть втроенные другие страницы и тогда одна статья может содержать не 2, а 4 и более файлов кеша.
- _index_slash_ssl.html
- _index_slash_ssl.html_gzip
Честно плохо понимаю почему их два, но как я понял один кеш, а второй архив для передачи сжатого контента, что бы быстрее все работало и меньше грузило саму сеть. В общем сжатый файл можно отключить в настройках плагина W3 Total Cache, но так как я порешал проблему с большим количеством файлов, то в целом это не актуально на данный момент для меня. Пусть будет еще и сжатый, в теории так лучше.
Итог
И вот только после всех этих изменений я смог снизить нагрузку на процессор с 10-12% до 6-8% и это очень хороший результат на мой взгляд. При этом страницы сайта даже лучше стали открываться, картинки грузятся равномерно и комментарии всегда актуальные для всех посетителей.
В будущем я еще планирую задействовать CDN, который так же есть в плагине W3 Total Cache и возможно получится сменить тариф хостинга с дорогого на более дешевый.
Дополнительно 11.12.2024
Да да, я писал статью очень долго
Интересно получается. Пока я готовил статью разработчики плагина сами нашли проблемы, с которыми я сталкивался и дали именно такие рекомендации как я описал в статье.
Пользователи с включенным Object Cache с помощью дискового хранилища должны обновиться до этой версии 2.8.1, чтобы обеспечить надлежащий сбор мусора. Для механизмов кэширования баз данных и объектов рекомендуется движок на основе памяти. Использование опции «Диск» может привести к большому количеству файлов кэша. Учетные записи хостинга с ограничениями inode могут возникать проблемы, включая простои, если будут достигнуты лимиты.
