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

Я сразу начал анализировать, что я такого делал на сайте в последнее время, но как оказалось, ничего не менял. Глянул на посещаемость, она была нормальной, то есть не выросла и никак не могла привести к увеличению нагрузки, причем к такому резкому.

Я сразу подумал, что сейчас хостинг отключит мои сайты. У меня в этой панеле, только один посещаемый сайт, примерно 10000 просмотров страниц в сутки, это не мало, для виртуального хостинга за 400 рублей в месяц. Но всегда нагрузка была примерно на середине, если допустимо на CPU 120, то у меня было 70.

Сел я писать в поддержку ihc письмо, объяснил ситуацию. Ответ пришел очень быстро, впрочем как и всегда. Написали, что за разовое увеличение нагрузки никто сайт отключать не будет, хууу, успокоили. Так же указали на сайт, который создает большую нагрузку и указали один IP адрес, который ведет себя очень странно и делает очень много запросов к сайту. Так же посоветовали проанализировать файл логов домен_access.log .

Тот IP адрес, который они указали, я сразу же заблокировал в файле .htaccess в корне сайта. Просто добавив строчку deny from **.***.***.** . И стал ждать, что на этом все закончиться и нагрузка на хостинг упадет.

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

На следующий день, вчера, нагрузка CPU на хостинг увеличилась еще больше при допустимых 120 было 300. И я решил, что нужно все таки разбираться в этих логах, и начал просматривать файл домен_access.log, который выкачал по FTP с хостинга. Большой такой файл, открыв его блокнотом, что-то там понять было сложно. Тут мне пригодился мой любимый Notepad++, там все отображалось с новой строчки, короче все как положено.

Долго я смотрел этот файл, там отображается IP адрес, время запроса, тип запроса и т. д. Посмотрел и закрыл. Сегодня утром проснулся, пошел смотреть что там с нагрузкой, она уже превышала допустимую. Решил, что нужно разбираться. Снова открыл лог сервера и начал внимательно его смотреть. Заметил несколько IP, с которых даже ночью очень активно шли запросы на сайт. Причем, за секунду могло быть более 10 запросов, к одной и той же странице сайта. И таких запросов было очень много. Все IP, которые мне показались странными я заблокировал в.htaccess.

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

После блокировки тех IP нагрузка вроде устаканилась. Ночью, когда IP еще не были заблокированы, нагрузка была заметна, а вот уже сегодня днем вроде все нормально.

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

Что касается самого хостига ihc.ru в этом деле, то мне кажется, что они молодцы. Во первых, сайт с десятью тысячами просмотров в сутки на виртуальном хостиге за 400 рублей в месяц, мне кажется, что это круто. За помощь в решении проблем с нагрузкой и поиском этих IP, так же большое спасибо.

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

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

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

Заголовок и 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" />

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

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

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

Для начала вам нужно будет получить доступ по FTP к файлам вашей темы оформления. Они находятся в папке:

/wp-content/themes/название_вашей_темы_оформления

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

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

; charset=" />

Нет, удалять его, конечно же, не надо, но вот немного видоизменить, убрав не нужные обращения к БД, можно:

Ну вот, два запроса в минус — пустячок, а приятно. Дальше — больше. Что еще можно заменить или удалить в HEADER? Давайте перечислим:

1. Удалить строку с информацией о номере установленной версии WordPress . Она не несет никакой полезной нагрузки и, более того, является опасной, т.к. некоторые варианты взлома применимы только к определенным версиям, а из этой строки как раз очень удобно узнавать текущую версию вашего движка. Выглядит эта строка обычно так: " />
2. Заменить URL до вашего файла таблицы стилей CSS в вашей текущей теме оформления на статический. В коде это строка: " type="text/css" media="screen" />

WP Tuner устанавливается на WordPress стандартным способом, а именно:

1. распакуйте архив, используя ftp-менеджер подключитесь к вашему блогу и загрузите папку wptuner в папку с плагинами wp-content/plugins/ на сервере хостинга
2. войдите в админку и выберете вкладку «Плагины»- «Inactive»
3. найдите строку с плагином WP Tuner и активируйте его

Если при установке плагина WP Tuner у вас возникли какие-либо затруднения, то можете обратиться к материалам статьи, про решение возможных проблем с установкой плагинов. Теперь можно зайти в админку и ознакомиться с настройками этого расширения (из левого меню выбрать Параметры -> WP Tuner.

Собственно, настроек у WP Tuner не так уж и много, к тому же для того, чтобы данный плагин начал показывать количество запросов к БД при загрузке страницы, вообще ничего менять не надо. Нужно просто зайти на блог, но при этом нужно, чтобы вы были под логином администратора, и открыть какую-либо страницу.

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



Обычные посетители блога, естественно, этого безобразия, внесенного WP Tuner, видеть не будут, только администратор, т.е. вы.

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

/wp-content/themes/название_вашей_темы_оформления/footer.php

и где-нибудь в его содержимое нужно вставить следующую конструкцию (место вставки будет определять область вывода числа запросов к БД в футере):

queries in seconds.

В результате после загрузки страницы, в самом низу (в области подвала), вы увидите, сколько при этом было сделано обращений к БД:

Удачи вам! До скорых встреч на страницах блога сайт

посмотреть еще ролики можно перейдя на

");">


Вам может быть интересно

Пропало левое меню в админке WordPress после обновления
Создаем для блога на WordPress кнопки добавления в социальные сети и закладки (без плагинов и скриптов)
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации Смайлики в WordPress - какие коды смайлов вставлять, а так же плагин Qip Smiles (красивые смайлики для комментариев) Как автоматически добавить атрибут Alt в теги Img вашего блога на WordPress (там, где их нет)
Hyper Cache - включаем плагин кэширования в Вордпресс для оптимизации WP блога и снижения его нагрузки на сервер хостинга

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

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

Проблема в wp-cron.php

wp-cron.php периодически запускает на сайте различные задачи: проверяет обновления WordPress и установленных плагинов, публикует запланированные посты, рассылает уведомления о новых комментариях и прочих событиях и т.д. Проблемы с wp-cron начинаются зачастую на виртуальных серверах, которые имеют ограничение на количество используемых системных ресурсов. В итоге создается экстремальная нагрузка на сервер.

Определив, что источником нагрузки является wp-cron.php, его можно отключить, добавив в файл wp-config.php строчку:

Define("DISABLE_WP_CRON", true);

Но без wp-cron сайт не будет полноценно функционировать. Тогда мы сами должны управлять его работой, это можно сделать через cPanel, создав cron-задачу (с необходимым интервалом на исполнение), например:

Wget http://ваш_сайт.ру/wp-cron.php?doing_wp_cron > /dev/null

Проблема в xmlrpc.php

В WordPress есть скрипт xmlrpc.php, он отвечает за вызов удаленных процедур и поддерживает известные API - WordPress API, Blogger API, MetaWeblog API и MovableType API. С помощью этого файла можно удаленно публиковать посты на своем сайте или полностью им управлять, не обязательно через административную панель. И как раз таки частые запросы к XMLRPC могут вызывать чудовищную нагрузку, что очень эксплуатируется на практике.

Если Вы вообще не используете в своей работе XMLRPC (а этого наверняка Вы не делаете), то можно просто удалить из корня своего сайта файл xmlrpc.php. А чтобы боты не грузили 404 страницу, в.htaccess добавляем редирект на microsoft.com (сервера у них хорошие):

Redirect /xmlrpc.php http://www.microsoft.com

Проблема в wp-login.php

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

Защита wp-login.php без плагина

в.htaccess добавляем:

Order Deny,Allow Deny from all

Файл wp-login.php, переименовываем в секретное имя, например cudanelza.php и внутри файла меняем все надписи wp-login.php на cudanelza.php.

Теперь у нас wp-login.php стал cudanelza.php

Защита wp-login.php с помощью плагина Lockdown WP Admin

Плагины - Добавить новый - ищем "Lockdown WP Admin". Ставим, активируем, переходим в настройки. Напротив "Yes, please hide WP Admin from the user when they aren"t logged in" ставим галочку. В разделе WordPress Login URL прописываем новый адрес админки, например, "parapara". Сохраняем настройки. Теперь наша админка доступна по адресу http://сайт.ру/parapara

Проблема в sitemap

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

Вот как выглядят дефолтные (по умолчанию) настройки XML карты сайта в плагине All in One SEO. В XML карту попадают все типы записей, которые там вообще не нужны:

Дефолтные настройки XML карты сайта в плагине All in One SEO

Именно дефолтные настройки XML карты сайта были частой причиной нагрузки на сервер, вызываемой поисковыми ботами и пауками.

Данная проблема решается в несколько этапов:

1. Настройте sitemap.xml таким образом, чтобы сюда попадали исключительно ссылки на страницы/записи вашего сайта

2. В robots.txt пропишите директиву

Crawl-delay: 10

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

3. Блокируйте ненужных Вам роботов. В статье вы найдете действенные методы блокировки ненужных ботов и пауков

Это не все, но тем не менее, наиболее распространенные ситуации в моей практике, когда WordPress создавал нагрузку на сервер. Как мы видели выше, не сам WordPress может создавать нагрузку, но и недоброжелатели, пытающиеся взломать, либо просто "повесить" Ваш сайт. Данные рекомендации будут актуальны в любом случае, не важно, у вас виртуальный или выделенный сервер. Естественно, большие проекты на WordPress требуют серьезных мощностей, развернуть серьезный сайт, не вызывающий нагрузок на виртуальном сервере - проблематично. Тут проще купить сервер или арендовать. Но и там без оптимизации WordPress не обойтись, особенно, если речь идет о высокопосещаемом сайте.

P.S. В WordPress имеются недостатки, которые рано или поздно могут привести к нагрузке на вашем сервере. Этими недостатками могут воспользоваться недоброжелатели, что чревато выходом за предоставленные хостингом лимиты. Надо быть готовыми к их устранению. Наиболее частые проблемы мы только что рассмотрели. Также в связи с этим напрашивается закономерный вопрос: почему озвученным аспектам так мало уделяют внимания разработчики WordPress? Это не проблема последних версий, а наиболее уязвимые места, которые передаются по наследству, от версии к версии! Разумеется, с помощью плагинов и обширного кодекса, WordPress можно адаптировать под практически любые нужды вебмастера, но вебмастерами зачастую выступают новички, поэтому хотелось бы видеть механизмы защиты обозначенных в этой статье проблем в дефолтных сборках WP. Тогда и взломов сайтов было бы меньше и нагрузок на серверах поубавилось!

Вконтакте

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

Со мной подобная история произошла в 2010 году. Посещаемость на моём первом блоге наконец-то появилась, медленно и уверенно подрастая. Радоваться долго не пришлось. Вскоре со мной произошло именно то, о чём я описал выше.

Все замечательно, все понравилось, кроме цены - 30 $. Тогда он стоил именно столько.

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

И вот настал день когда я впервые, вместо одного из вордпрессовских плагинов для кеширования, установил MaxCache. В 2013 году делая блог о спутниковом телевидении, я решил использовать для кеширования блога именно его.

Поюзал два дня бесплатную лайт-версию, укрепился во мнении, что иду правильным путём, и приобрёл платную Full-версию.

Теперь, когда я делаю кому-либо блог, или запуская что-то своё, не задумываясь, устанавливаю для кеширования блога MaxCache.

Как видите, и на этом блоге для снижения нагрузки на сервер стоит именно он. На сегодняшний день цена MaxCache составляет 10 $.

Алгоритм работы - как MaxCache снижает нагрузку на сервер

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

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

Открываете файл footer.php вашей темы, и вставляете следующий код перед закрывающимся тегом .

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