Этот код выводит потребление памяти, количеств запросов к 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. ;-)

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

Нагрузка на хостинг увеличилась значительно, при количестве хитов положим 500—600 wordpress уже превышал лимиты на использование ресурсов MySQL в три раза, а значит выход стоял либо в кеше (довольно геморном опять же в wordpress), либо в переходе на другой движок.

Я испробовал на локали большинство готовых блоговых движков и пришел к неутешительному выводу:
ни один из них (!) даже при наличии импорта из wordpress, не мог предоставить той же структуры ЧПУ (и уж тем более в автоматическом, интуитивном режиме), а это значит при переходе -> 301 редирект и непонятно какая реакция со стороны ПС в плане существующих позиций.

В итоге получилось как всегда: посмотрел сорцы wordpress, импортнул данные из существующей БД, написал небольшое подобие CMS.

Нагрузка: на MySQL снизилась в среднем в 10 раз, на проц — в 2 раза. Думается мне, что здесь есть еще где развернуться в плане оптимизации, но согласитесь даже это уже показательный результат!

Вывод из данного поста совсем не в том, чтобы всем ринуться срочно писать свои скрипты (подумайте хотя бы о защите от взлома), а в том, чтобы пару раз подумать прежде чем ставить wordpress в качестве блог-движка, ведь потом может быть проблематично сменить ЧПУ и уж тем более адреса существующих ссылок (если они, конечно, не покупные).

15 Комментариев

1. 1

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

2. 2

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

3. 3

   Всегда в сети говорили, что ВП лёгкий, и я верил, хоть и использую по жизни Drupal. Потом в сентябре у меня появился заказчик, с желанием «Съехать с этого глючного ВП нах на друпал». Оказалось следующее:
   1. Сайт крутился на VPS 500Mhz и 384 рамы
   2. Посещаемость около 1000 хитов в сутки.
   3. Включены все мыслимые и немыслимые кеши.
   Вся эта система стабильно раз в сутки падала, в остальное время безбожно тормозила. Начался суровый и кропотливый процесс переезда на друпал, в итоге:
   1. Все материалы перетянули.
   2. Где урлы устраивали, оставили их, где не устраивали, сделали новые урлы, на старые 301 редирект.
   3. Переехали абсолютно без потерь. С той же функциональностью, а в некоторых местах даже больше.
   Сейчас загрузка сервера по процессору в самые жесткие моменты, когда приходит Гоша и Яша не превышает 30 процентов, с отключенным кешированием.
   Так что, подумайте о друпале, не так он хренов, как все говорят.
   Вот пациент - surlaterre.ru

4. 4

   Ничего против Друпала не имею, хорошая система. Основная моя претензия - в современных движках нет простой системы переезда с другой CMS с сохранением старой системы ЧПУ.

5. 5

   Если взять тот же переезд с ВП, то существующий модуль переносит вместе с ВП-шными урлами, но я переносил своим модулем, у меня несколько иначе было всё

6. 6

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

7. 7

   В общем могу сказать: «Ничего не переносимого нет», если тема интересна, то велком в аську/почту/скайп. Контакты на моём сайте

8. 8

   Не знаю как у вас был настроен WordPress, сервак и кеши. Но у меня на обслуживании стоят сайты на WP у которых на виртуалках посещалка 4000 в сутки и ни каких проблем. Есть сайты с посещалкой на 10 000 в стуки, но на приватах. Там нагрузка не превышает 10% в пиках. Так что WP рулит еще как!

9. 9

   Я сейчас осваиваю MovableType. Эта CMS несмотря на необычность (используется perl, генерит статические html), очень легкая и достаточно функциональная. Быстрее WP в разы.

10. 10

    MovableType хорош, но информации на русском о нем все же мало.

11. 11

    Я лично вообще не могу разобраться какая там эта нагрузка. У меня крупных проектов WP ни когда не было и проверить я это сам не могу. А где бы я ни почитал, дак ни чего не поймешь одни говорят wp-рулит, другие говорят что фигня движок. А вообще какая все таки нагрузка и и какую wp может выдержать я ни где не встречал. Остается один вопрос почему тогда wp по зоне ru находится на лидирующих позициях?Может из-за своей простоты?

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

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

Тем самым мы уменьшим количество обращений к базе данных 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 блога и снижения его нагрузки на сервер хостинга

Привет. После попыток взломать один из моих сайтов, об этом я писал в статье , все было как-то спокойно, нагрузка на хостинг стала нормальной и проблем не было. Но в один прекрасный момент, захожу я в панель 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, так же большое спасибо.

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

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

Вход в админку у меня был стандартный и дополнительно не был защищен. Подход банальный, если ничего не случилось, зачем что-то делать? Подход резко изменился, когда хостинг ТаймВеб за нестабильную работу сервера вынужден (он бы не прочь, но я его вынуждаю;)) приостановить обслуживание моего аккаунта.

Брутфорс – это и есть подбор пароля и логина путем перебора множества вариантов. В результате таких манипуляций растет количество запросов и увеличивается нагрузка.

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

Как уменьшить нагрузку на сервер с WordPress?

Самые вкусные файлы для взломщиков wp-login.php и wp-config.php. Для уменьшения нагрузки на сервер им необходимо уделить особое внимание, а для защиты админки следует присмотреться к следующим способам.

Первый способ. Закрыть полный доступ к wp-login.php для всех IP адресов, кроме вашего. Для защиты достаточно внести изменения в файл.htaccess. То есть доступ к админке будет разрешен только вам, у остальных будет выкидываться ошибка.

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

Второй способ. Спрятать файл wp-login.php. Этот способ оказался для меня идеальным.

1. Переименовываем название файла wp-login.php в, например, 45jkdsf234.php . Искать файл нужно в корне сайта, корректировать либо через админку хостинга либо через .

2. Заменяем все встречающиеся слова wp-login.php на переименованные, в моем примере на 45jkdsf234.php . Изменения нужно внести в старый файл wp-login.php , который сейчас называется 45jkdsf234.php и в wp-includes/general-template.php .

Теперь вход в админку будет осуществляться не по адресу ваш-сайт/wp-login.php , а по адресу ваш-сайт/45jkdsf234.php .

3. Добавить в.htaccess перед # END WordPress такой код:

В результате у меня получился такой.htaccess:

Третий способ . Использовать плагин Login LockDown, который предотвращает попытки подбора пароля. Установка плагина банальная, поставил и забыл. По умолчанию имеется 3 попытки войти в админку в течение 5 минут, при неудачных попытках происходит блокировка по IP на 1 час.

Мне очень не хотелось ставить Login LockDown, обычно я подбираю пароль к админке раза с 5-го. Но что сделаешь, придется тренировать память, лучше так, чем постоянные взломы.

Вот так выглядит график нагрузки до и после подбора пароля:

Период взлома отчетливо виден по резким скачкам графика.

Что не помешает сделать вебмастеру для снижения нагрузки WordPress на сервер

По максимуму обезопасить админку позволит следование базовым правилам по соблюдению безопасности:

• На админку стоит поставить сложный пароль;
• Поменять логин admin на другое название;
• В FTP-клиентах не хранить пароли и логины;
• Регулярно делать back up файлов вордпресс и базы данных mysql. Про создание автоматической резервной копии базы .

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

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

На самое сладкое видео с заманчивым названием.