Высокая нагрузка WordPress на CPU — процессор, сервер и хостинг. Оптимизация темы (шаблона) WordPress для снижения его нагрузки на сервер хостинга, плагин WP Tuner и число запросов к БД

Нагрузка на сервер снизилась более чем в 14 раз!

Количество обращений к базе данных при использовании скрипта нулевое!

Скорость генерации страницы увеличилась в 2720 раз!

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

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

Кеш страниц сбрасывается каждые 4-е часа. При желании можно указать собственные настройки.

В комплекте со скриптом идёт плагин, который при активации позволяет нам когда мы залогинены, и работаем в админ панели блога просматривать не кешированные актуальные версии страниц. Для посетителей в это время, как и положено скрипт выдаёт их из кеша.

Имеется возможность включения gzip-сжатие трафика. Увеличивает скорость загрузки «тяжёлых» страниц. Включение gzip-сжатия даёт дополнительную нагрузку на сервер. Включать или нет эту функцию нужно принимать решение исходя из наличия лимитов по нагрузке CPU. Перед включением gzip-сжатия нужно уточнить у хостера поддерживается ли эта функция сервером.

Я на страницах при написании статей часто использую картинки и скриншоты. Хотя и сжимаю их по максимуму, вес выходит не всегда такой какой бы хотелось. У меня gzip-сжатие включено.

Результаты для главной страницы получились следующие.

До сжатия вес моей страницы был 23,7 KB, после компрессии 6,5 KB. Экономия составила 72,4%. Как говорится - Без комментариев. Сервис проверки работы gzip-сжатия находится по этому адресу - http://www.whatsmyip.org/http_compression/ .

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

В завершение статьи, хотелось бы подчеркнуть, что мне нравится подход автора скрипта к его продажам. После оплаты MaxCache покупатель получает Lite -версию скрипта. Эта версия с ограниченным функционалом. Отличается она от Full-версии, тем, что кеш не сбрасывается на автомате. То есть урезанная версия работает, практически так же, как и полная. На тестирование автор выделяет две недели времени. Далее, вы или отказываетесь от приобретения, и автор возвращает вам деньги либо отправляете заявку на получение full-версии MaxCache.

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

Вконтакте

Давайте наверное уже начнем оптимизировать Поехали!

Пример излишней нагрузки на сервер.

Допустим пользователь зашел на сайт, но что происходит при открытии страницы? Как информация выводится на экран? Давайте проследим сей процесс на примере заголовка сайта.

Заголовок и URL главной страницы сайта, если Вы помните, задается в настройках WordPress: адимнка -> Параметры -> Общие. Все настройки, имеющиеся во вкладке «Параметры», заносятся в базу данных, а точнее, в таблицу wp-options , откуда в последствии они запрашиваются различными функциями и выводятся на экран.

Разработчиками WordPres написано не мало функций, но сами по себе они выполняться не могут. Для полноценной их работы необходимо некое связующее звено, в роли которого выступает шаблон сайта.

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

В большинстве шаблонов, главный заголовок сайта заключен в тег h1 , поэтому ищем участок кода с данным тегом. В моем шаблоне код вывода заголовка выглядел так:

/">

Отлично, заголовок должен быть ссылкой, поэтому в коде присутствие конструкция анкор . Но вот что это вместо ссылки прописано? Да и анкор какой-то странный. А ведь это и есть наглядный пример излишней нагрузки на сервер.

С анкором мы разберемся немного позже, а сейчас давайте познакомимся с функцией get_option() .

Функция get_option() и нагрузка на сервер

Итак, мы вписали название и URL главной страницы сайта в настройки WordPress и они отправилось на хранение в БД, в таблицу wp-options .

В момент, когда пользователь открывает любую страницу нашего ресурса и файл header.php начинает подгружать шапку, происходит активация функции get_option().

Принцип работы вышеупомянутой функции заключается в обращении к базе данных, а точнее к таблице wp-options и в получении от туда определенных данных, исходя из заданных параметров. После чего, команда echo выводит полученные данные на экран.

Немного сложновато, ну нечего, сейчас я все разъясню. В скобках указывается параметр, в нашем случаи get_option(‘home’) , который сообщает функции, какой тип данных ей надо получить.

Параметр home дает команду функции запросить из БД URL главной страницы. Стоп! Значит URL главной страницы тоже хранится в базе данных? Верно. И при открытии страницы функция его запрашивает, т.е, происходит обращение к данным, которые хранятся на сервере.

А теперь представьте, что на Ваш ресурс зашли 100 посетителей и начали «шалить», открывая все новые и новые страницы.

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

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

Вернемся к функции get_option() . Для получения из БД тех или иных данных, функция может принимать следующие параметры:

get_option("home") — URL главной страницы
get_option("admin_email") — E-mail администратора сайта;
get_option("blogname") — Название сайта;
get_option("blogdescription") — Краткое описание сайта;
get_option("blog_charset") — Кодировка сайта;
get_option("date_format") — Формат даты;
get_option("default_category") — Категория по умолчанию;
get_option("siteurl") — Адрес WordPress (см. Параметры -> Общие);
get_option("start_of_week") — Первый день недели;
get_option("upload_path") — Каталог загрузки по умолчанию (устаревшая);
get_option("posts_per_page") — максимальное число постов на странице;
get_option("posts_per_rss") — Максимальное число постов в RSS-ленте;

Большинство перечисленных типов данных указываются в настройках WordPress, во вкладке «Параметры». Исключением являются: «Кодировка сайта» — указывается непосредственно в БД и «Каталог загрузки по умолчанию «- опция была убрана из настроек с версии 3.5.

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

Как и чем заменить функцию get_option() я расскажу немного позже, а пока давайте выясним, что за bloginfo() прописана в коде вместо анкора.

Функция bloginfo() и нагрузка на сервер

Вернемся к тому моменту, когда пользователь открыл страницу. Мы выяснили, что URL адрес главной страницы был взят из базы данных, средствами функции get_option(‘home’) .

Ну хорошо, а сам заголовок откуда взялся? Заголовок также хранится в базе данных, но в нашем случаи он был получен и выведен на экран другой функцией — bloginfo() .

На заметку! bloginfo() — это тег шаблона, который активирует функцию get_bloginfo() . Может использоваться в любом месте шаблона.

Функция bloginfo() может принимать следующие параметры:

bloginfo("url") — Выводит URL сайта;
bloginfo("name") — Выводит название сайта;
bloginfo("description") — Выводит описание сайта;
bloginfo("template_url") — путь до директории текущей темы;
bloginfo("template_directory") — тоже самое, что и "template_url";
bloginfo("stylesheet_url") — путь до файла стилей текущей темы;
bloginfo("stylesheet_directory") — тоже самое, что и "stylesheet_url";
bloginfo("charset") — Выводит кодировку сайта;
bloginfo("admin_email") — Выводит e-mail адрес администратора;
bloginfo("version") — Выводит версию WordPress;
bloginfo("html_type") — Выводит данные из html_type таблицы wp-options;
bloginfo("pingback_url") — путь до файла xmlrpc.php;
bloginfo("rss2_url") — Выводит URL фида RSS 2.0 (домен/feed);
bloginfo("comments_rss2_url") — Выводит URL фида комментариев (домен/comments/feed);
bloginfo("rdf_url") — Выводит URL фида RDF-RSS 1.0 (домен/feed/rfd);
bloginfo("rss_url") — Выводит URL фида RSS 0.92 (домен/feed/rss);
bloginfo("atom_url") — Выводит URL фида Atom (домен/feed/atom);

Функция bloginfo() немного отличается от функции get_option() , но работает по схожему принципу, т.е, запрашивает из БД те или иные данные и выводит их на экран.

Стоит сказать, что существуют разные мнения по-поводу создаваемой функцией bloginfo() нагрузки на север. Но нагрузка однозначно имеет место и если есть возможность ее снизить, то грех такой возможностью не воспользоваться.

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

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

Конечно, меры которые я предпринял, касаются не только сокращения запросов к БД и я постепенно обо всем расскажу, но в одну статью, сей объемный материал, мне не запихнуть.

Так что ожидайте новых потов, посвященных скорости загрузки страниц и чтобы их не пропустить, подписывайтесь на обновления блога .

Технология сокращения запросов к БД

Напомню, как выглядит код заголовка в моем файле header.php:

/">

А теперь, самое интересно. Если заглянуть в исходный код, то код заголовка там примет совершенно другой вид:

Вот такой код заголовка и должен быть прописан в файле header.php. Тогда сервер избавиться от двух совершенно лишних обращений, умноженных на количество открытых страниц.

Но тогда зачем в файлах шаблона прописываются вышеупомянутые функции?

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

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

Поэтому, начиная с файл header.php ищем участки кода, с вышеупомянутыми функциями, затем смотрим, как они выглядят в исходном коде и заменяем.

Для закрепления материала я приведу несколько примеров. Вот код, который выводит информацию о кодировке.

; charset=" />

Смотрим исходный код:

Копируем строчку целиком, и вставляем вместо кода с функциями.

Код подключения файла style.css:

" type="text/css" media="screen" />

Путь до таблицы стилей выведен с помощью функции bloginfo(‘stylesheet_url’) . Смотрим исходный код:

/images/fav.ico" type="image/x-icon" />

Для 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 ) сайта следующий код:

WordPress: " . round(memory_get_usage()/1024/1024, 2) . "MB " ." | MySQL:" . get_num_queries() . " | "; timer_stop(1); echo "sec