О нагрузке WordPress-сайтов

22-09-2012Время чтения ~ 10 мин.PHP 32314

Поскольку я продаю свой кэш MaxCache для WordPress, то практически каждый день получаю письма с просьбой умерить аппетиты этого монстра. Как правило блогеры не задумываются об этой проблеме в начале создания сайта, и остро она стоит уже когда хостер присылает уведомления с угрозой отключить сайт.

Как правило, первое, что делает блогер - это устанавливает кэширующие плагины. Нагрузка, если и уменьшается, то незначительно. Далее, начитавшись «якобы гуру», начинают самостоятельно «оптимизировать» шаблон или даже сам WordPress. Тут можно только посочувствовать, особенно умиляют советы о включении например gzip-сжатия в самом шаблоне. Стоит ли говорить, что подобные действия в самом лучшем случае не приводят к результату вовсе, либо, наоборот нагрузка на сервер ещё больше увеличивается.

Попробуем разобраться, почему так происходит и что делать в подобных ситуациях.

MaxCache и другие кэши

Самый простой и радикальный способ снизить нагрузку WordPress - это установить мой MaxCache. Мой кэш принципиально отличается от любых других кэширующих плагинов, потому что он не плагин и работает вне WordPress. Если другие плагины загружаются в рамках WordPress, то мой - работает вне, тем самым и достигаются столь высокие характеристики.

Поэтому первая причина, по которой существующие плагины-кэши работают неэффективно - это то, что они сами по себе ресурсоёмкие и для своей работы требуют наличия WordPress. То есть вместо снижения нагрузки, получается с точностью наоборот - нагрузка увеличивается.

«Кэширование» в .htaccess

Некоторые плагины для «ускорения» WordPress меняют файл .htaccess, прописывая в нем инструкции для принудительного кэширования файлов для браузеров на длительное время. Технически браузер не загружает файл с сервера сразу, а вначале проверяет его наличие в своём кэше (на компьютере). Для этого он посылает короткий запрос серверу и сервер может возвратить ответ «Файл не изменился». То есть браузер уже не тянет его с сервера, а берёт из своего кэша. Понятно, что скорость загрузки страницы в этом случае возрастает многократно.

Указание «принудительного кэширования» в .htaccess практически не имеет смысла поскольку не зависимо от этих инструкций, первоначально все файлы должны быть загружены пользователем. Поскольку повторных посетителей (раз-два в неделю) гораздо меньше новых, то эффективность такого кэширования небольшая. Кроме того, следует учитывать тот факт, что браузеры достаточно умны и самостоятельно определят нужно ли загружать старые файлы.

Таким образом «кеширование» в .htaccess можно использовать, но это только лишь может сказаться на трафике для повторных посетителей.

Сжатие с помощью gzip

Другой частой ошибкой является включение gzip-сжатия. Само по себе сжатие позволяет сократить трафик примерно на 30%, но только для текстовых файлов. Как правило файлы изображений плохо сжимаются и выигрыш будет очень маленький.

Проблема здесь в том, что сжатие требует дополнительных ресурсов сервера, что приводит к ещё большей нагрузке. То есть включать сжатие имеет смысл только выборочно и только при наличии свободных ресурсов сервера.

Само сжатие должно быть включено на уровне сервера. Обычно эту инструкцию прописывают в .htaccess.

Не путаем трафик и нагрузку на сервер!

Неопытные блогеры иногда мне присылают скриншоты разных онлайн-сервисов о том, что мой кэш якобы не уменьшает «нагрузку». Приходится объяснять, что загрузка сайта пользователем и нагрузка на сервере - совершенно разные вещи.

Нагрузка на сервере характеризуется несколькими основными показателями. В первую очередь - это загрузка процессора (CPU). Обычно измеряется от 0 до 100% (или от 0 до 1). 100% - это значит, что процессор полностью загружен в заданный промежуток времени, например за 1 минуту.

Хостеры как правило учитывают этот показатель и закладывают лимиты в тарифные планы. Например для дешёвых тарифов CPU может ограничиваться 2-3%, а дорогих 10%. При этом предполагается учёт пиков: например в течение 30 секунд сайт может потреблять 70% CPU.

Виртуальный хостинг - это одна большая коммунальная квартира. Ресурсы у неё ограничены, а жильцов много. Поэтому, когда один жилец (сайт) засел в туалете на полчаса, другие вынуждены его ждать. Вот поэтому хостеры и лимитируют использование туалета ресурсов.

Проверить использование CPU на сервере можно только, если хостер предоставляет такую возможность. На странице кэша в отзывах есть примеры скриншотов. Возможно ваш хостер предлагает похожую статистику.

Нагрузка в виде «процессорного времени»

Когда-то давно хостеры использовали только ограничение на трафик. То есть нужно было платить только за объем скачанной информации. После, сделали трафик безлимитным (точнее очень большим), но ввели ограничение на использование CPU. То есть те же самые сайты, которые раньше спокойно работали на сервере, вдруг стали не укладываться в отведенные лимиты CPU.

Сейчас хостеры придумали очередную «забаву» в виде «процессорного времени». Если раньше был лимит на CPU, который просто не стоит превышать, то процессорные минуты «капают» всегда. Например хостер выделил на аккаунт 100 минут в сутки. Не зависимо от того, превысили ли вы лимиты процессора или нет, берется его загрузка и вся суммируется. То есть даже если за вами очереди в туалет нет, хостер учтёт всё время посещения.

Плохая новость для WordPress-блогеров в том, что, как правило выделенных процессорных минут (обычно 100 минут) хватит примерно для 2 тысяч хостов в сутки. Если посещаемость превышает 2000 посетителей, то для сайта на WordPress превышение процессорного времени будет 10-100% (110-200). То есть хостер вышлет уведомление с просьбой уменьшить нагрузку либо перейти на более высокий тариф.

Потребляемая php-память и MySQL

Давно известно, что WordPress-разработчики давно «забили» на оптимизацию своего «движка». Вместо этого тупо увеличили минимальные требования к серверу. Именно поэтому WordPress требует для работы как минимум 32Мб памяти, а для админки 256МБ.

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

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

Что касается MySQL - запросов к базе данных, то тут более сложная ситуация. Запросы бывают разные. Существую короткие, но затратные по ресурсам sql-запросы, а бывают длинные, но быстрые. То есть в целом, если хостер жалуется на превышение лимитов MySQL, следует провести анализ запросов и выявить медленные. Это задачка для опытного вебмастера, а для рядового блогера решается путем отключения плагинов и/или смены шаблона. Но, в любом случае, использование базы данных достаточно затратно для сервера, поэтому всегда следует стремиться к уменьшению количества запросов MySQL.

Чтобы получить статистику своего сайта добавьте в подвал (как правило файл footer.php) сайта следующий код:

<?php
    echo '<div style="text-align: center">WordPress: '
        . round(memory_get_usage()/1024/1024, 2) . 'MB '
        .' |  MySQL:' . get_num_queries() . ' | ';
    timer_stop(1);
    echo 'sec</div>';
?>

Этот код выводит потребление памяти, количеств запросов к MySQL и общее время, которое потратил сервер на формирование страницы.

Память должна быть где-то до 15-20МБ (мы говоим о WordPress! Для нормальных сайтов - не более 8-10Мб). Запросов - до 30-40, если их более 100, то не откладывайте вопросы оптимизации. Время будет зависеть от мощности сервера, но обычно приемлемо менее 1 секунды. Причем обязательно нужно снять время несколько раз, просто обновляя страницу (F5): на время может влиять объем трафика страницы и используемого кэша. Я бы рискнул назвать «пограничным» значением - 0,5 секунд. Если время больше, значит нужно подумывать об оптимизации, если более 1 секунды - то тут уже без вариантов.

Трафик

Трафик сейчас особо не влияет на нагрузку сервера, поскольку результирующий php-код по объему занимает небольшую часть трафика. Однако, следует учитывать, что большой трафик напрямую влияет на скорость загрузки страниц посетителями.

Самый простой вариант быстро проверить объем трафика - воспользоваться «Информация о странице» в FireFox.

Думаю, что нормальный размер страницы - менее 50Кб. Если размер больше, то стоит подумать об оптимизации.

Также необходимо заглянуть на вкладку «Мультимедиа». Как правило именно здесь скрывается основной источник повышенного трафика. Вообще любой блогер должен сделить за выкладываемыми файлами и выполнять оптимизацию загружаемых изображений в фотошопе или аналогичных программах. Тут рекомендация одна - чем меньше размер файла, тем лучше. Если размер файла более 100-200Кб, то стоит рассмотреть вариант его размещения в виде миниатюры или даже замены.

Следующий источник трафика - js-скрипты и css-файлы. Можно воспользоваться «Веб-консолью», но удобней воспользоваться расширением HttpFox. HttpFox выдаёт http-заголовки, размер, все адреса и прочую информацию, глядя на которую можно оценить затраты на трафик и время загрузки каждого файла.

Обратите внимание на 304-заголовок - это ответ сервера, что файл не изменился и браузер его возьмет из своего кэша.

Очень часто в WordPress'е загружают несколько копий jQuery. Каждая из них весит примерно по 100Кб, так что есть смысл проанализировать кто «безобразничает» и наказать «сорванца». :-)

Также обратите внимание на сторонние скрипты, например счетчики. Строго говоря, анализаторы трафика не должны учитывать сторонние загрузки, но сейчас ситуация такая, что учитывается всё. Например Google Analitics может загружаться за 5 секунд (Яндекс-метрика ещё дольше, да еще и картинку и ссылку свою лепит), это время войдет в общую загрузку. То есть к таким анализаторам следует подходить с умом, отделяя мух от котлет.

Общие рекомендации

Понятно, что основная проблема WordPress'а - это сам WordPress. Точнее наплевательское отношение к оптимизации кода начиная от самих разработчиков, до плагино/шаблоно писателей и самих блогеров. Данный факт в WordPress'е доведен до абсурда. В wp-config.php вы можете ради интереса временно включить режим отладки (точнее отображение ошибок):

define('WP_DEBUG', true);

Впрочем, ситуацию всё равно не изменить, но можно попытаться хоть как-то минимизировать.

На сервере:

• Проверьте логи php-ошибок на сервере. Если есть какие-то ошибки, то их следует исправить. В любом случае ошибки должны исправляться, а не скрываться.
• Если есть возможность, попробуйте на сервере включить eAccelerator и PHP как fastCGI. Это позволит немного оптимизировать работу PHP и уменьшит расход памяти.
• Если позволяют финансы, то лучше перейти на VDS (виртуальный выделенный сервер). Здесь уже все ресурсы будут своими и никто не укажет на превышение нагрузки. Правда следует учитывать, что как правило VDS слабее обычного виртуального хостинга и скорость работы сайта уменьшится. Думаю, что нет смысла брать VDS с CPU менее 2ГГц и памятью менее 1Гб.
• Учитывайте, что нагрузка на сервере считается по всему аккаунту. Если у вас несколько сайтов, то следует оптимизировать каждый из них.

В самом WordPress:

• Отключите все неиспользуемые плагины. Любой активированный плагин, даже если он не используется, всё равно требует каких-то ресурсов. Такие плагины следует включать только перед использованием. Это касается всяких бэкапов, статистики и т.п.
• Отключите «спорные» плагины, вроде запрета копирования. Это глупость, которая обходится любым пятиклассником. Вообще, все плагины, без которых ваш сайт может обойтись, следует отключить.
• Поменьше работайте в админ-панели. Админ-панель очень прожорлива в создает большую нагрузку, особенно на страницах загрузок файлов.
• Используйте приведенный мной код статистики потребления ресурсов. Чтобы статистика не была видна на сайте, её можно расположить в html-комментарии.
• Количество говнокода в плагинах WordPress - просто поражает! Такое впечатление, что у плагинописателей одна цель - нанести как можно больший вред сайту. Поэтому по возможности проверяйте каждый используемый плагин на нагрузку. Возможно есть аналог, написанный не так похабно.
• Если сайт потребляет слишком много ресурсов, возможно дело в шаблоне. WordPress-шаблоны, к сожалению, часто делаются слишком ресурсоемкими, поскольку разработчики WordPress полностью сосредоточены на красотах админ-панели и не предлагают вебмастерам удобных и эффективных решений. Поэтому они вынуждены придумывать код, который часто не всегда хорош.

Радикально:

• Используйте MaxCache. Он тоже является «костылём», но если другие варианты не помогают, то кэш позволит хоть как-то привести WordPress в чувства. При этом очень осторожно используйте другие кэши. Обязательно отслеживайте показатели статистики до и после. Доверяйте не красивым текстам, а реальным цифрам.
• Смена «движка» на что-то более легковесное, например MaxSite CMS.

Если ничего не помогает:

• Перейдите на более старую версию WordPress. Я бы посоветовал WordPress 2.3.3, причем моей сборки, поскольку в ней реализован lite-перевод, а также подобрана неплохая коллекция плагинов. Шаблон, да, скорее всего, придется переделывать, но оно того стоит: технически шаблоны WordPress застряли в каменном веке и делаются одинаково с версии 1.5.
• Отключите русский перевод. Русский перевод сейчас занимает почти 700Кб. И это только сам файл, не считая ресурсов на его загрузку, обработку и вывод. Отключив русский перевод, можно получить довольно существенное ускорение работы сайта.

Ну и на последок. WordPress - очень прожорлив. Поэтому не нужно думать, будто бы эта проблема обойдёт вас стороной. При увеличении посещаемости уже до 200 хостов хостер предложит перейти на более высокий тариф. При 2 тысячах - потребуется уже отдельный сервер или переходить на MaxSite CMS. В любом случае всех этих трат можно было бы заранее избежать, если сразу пользоваться нормальными CMS. ;-)