Доброго времени суток, уважаемые читатели блога сайт. Сегодня я хочу поговорить о том, как снизить нагрузку на сервер хостинга, создаваемую . Другими словами, мы займемся оптимизацией этого движка для снижения нагрузки на сервер хоста.
Но вы то знаете как называется ваш проект и совсем не обязательно обращаться для этого к базе данных при открытие любой его страницы. Поэтому, после того как вы уже окончательно определитесь с выбором шаблона, можно спокойно заменить в его файлах участки кода, реализующие запросы к БД, на конкретные названия, пути и т.п. ().
Тем самым мы уменьшим количество обращений к базе данных WP при загрузке любой из страниц блога, а это уже не мало. Теперь давайте перейдем от теории к конкретике и посмотрим, что реально можно подправить.
Для начала вам нужно будет получить доступ по FTP к файлам вашей темы оформления. Они находятся в папке:
/wp-content/themes/название_вашей_темы_оформления
Начнем с уже упомянутого выше — HEADER . Думаю, что с Файлзилой вы уже знакомы и доступ по ФТП к хосту для вас не в новинку. Если нет, то вверху есть окно поиска и достаточно будет ввести туда слово «файлзила» или «нотепад», чтобы получить самую полную информацию по этим двум архиполезным программам.
В HEADER реализовано достаточно много обращений к базе данных, которые спокойно можно заменить на статичные данные или же вообще удалить. В самом верху вы, наверняка, увидите следующий участок кода:
; charset=" />
Нет, удалять его, конечно же, не надо, но вот немного видоизменить, убрав не нужные обращения к БД, можно:
Ну вот, два запроса в минус — пустячок, а приятно. Дальше — больше. Что еще можно заменить или удалить в HEADER? Давайте перечислим:
- Удалить строку с информацией о номере установленной версии WordPress . Она не несет никакой полезной нагрузки и, более того, является опасной, т.к. некоторые варианты взлома применимы только к определенным версиям, а из этой строки как раз очень удобно узнавать текущую версию вашего движка. Выглядит эта строка обычно так: " />
- Заменить URL до вашего файла таблицы стилей CSS в вашей текущей теме оформления на статический. В коде это строка: " type="text/css" media="screen" />
- распакуйте архив, используя ftp-менеджер подключитесь к вашему блогу и загрузите папку wptuner в папку с плагинами wp-content/plugins/ на сервере хостинга
- войдите в админку и выберете вкладку «Плагины»- «Inactive»
- найдите строку с плагином WP Tuner и активируйте его
WP Tuner устанавливается на WordPress стандартным способом, а именно:
Если при установке плагина 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 блога и снижения его нагрузки на сервер хостинга
Прошел период примерно в 30 дней, в работе сайта больше проблем нет и высокая нагрузка на сервер, процессор больше не наблюдается. Теперь следует рассказать как мне удалось справиться с периодической высокой нагрузкой WordPress на процессор и сервер.
Все началось совершенно спонтанно и с каждым днем ответ сервера становился все более долгим. Затем в один прекрасный момент в панели webmaster Yandex, появилось соответствующее критическое уведомление. В котором был указан долгий ответ сервера практически на 40 — 50 страницах сайта. Все по-порядку.
Содержание статьи:
Высокая нагрузка создаваемая WordPress сайтом на серверный процессор CPU — основные симптомы этой проблемы
На моем сайте проблема возникала совершенно спонтанно и в разные временные периоды. Толчком 100% нагрузки на CPU сервера становились переходы между страницами сайта. Примерно на 2-й странице, возникал резкий скачек в работе процессора сервера. Хочется заметить, что в этот момент оперативная память практически не имеет колебаний. А количество процессов совершенно незначительно и не должно так пагубно нагружать серверный процессор.
Основные характерные признаки нагрузки, которые встречаются у многих вебмастеров:
- Повышение лимита нагрузки процессора на хостинг-сервере.
- WordPress начал создавать недопустимую нагрузку на CPU.
- Пиковые значения, жесткая перегрузка процессора на хостинге.
- Долгий ответ сервера, варьируемое значение колеблется от 5 до 30 секунд.
- Чрезмерная нагрузка происходит спонтанно, в разные временные периоды.
- Происходит заторможенность сайта, страницы практически не загружаются или этот процесс проходит очень долго.
- Сайт в пиковых пределах крашится.
- WP создает долгий ответ сервера, сайт работает не стабильно. В пиковых скачках CPU, оперативная память работает в штатном стабильном режиме.
- Количество затронутых и исполняемых процессов в периоды скачков минимальны.
- Потоковое пакетное обращение и задействованные соединения на nginx или apache минимальны.
- Данная аномалия проходит несколько раз в день, в разные промежутки времени. Заканчивается также быстро, как и началась.
Это именно то, что происходило с моим сайтом в течении месяца. Наглядным примером будут следующие изображения:
Как видите количество задействованных процессов минимально. Оперативная память удерживается в стабильном значении, с учетом открытого браузера и огромного количества страниц. А вот все ядра CPU работают в критической нагрузке, изначально причину понять вообще невозможно.
Какие методы я перепробовал в борьбе с критической нагрузкой на CPU
Самое банальное, я грешил на плагины WP и нехватку памяти. Хотя так по-честному, движок использует всего 16 мб памяти из допустимых 512 мб которые я выделил. Что собственно я пробовал:
- Провел полное обновление Debian, затем почистил всю систему.
- Удалил 99% сохраненных ревизий баз данных на VestaCp.
- Раз двадцать просматривал конфигурационные файлы в VestaCp на наличие ошибок.
- Нашел в почтовом сервере Exim большое количество системных логов (полностью удалил).
- Проверял сайт на наличие вирусов (отсутствуют).
- Делал трассировку до сайта, проверял скорость интернет соединения.
- На сайте отключил сохранение ревизий записей, большего на сайте не предпринимал. Сайт оптимизирован под 98% смысл его проверять.
После всех проделанных действий, проблема не решилась. В течении месяца скачки и пиковые критические нагрузки WP на процессор сервера продолжились.
В чем собственно заключалась проблема чрезмерной нагрузки WP на CPU, и как я ее решил
Проблема заключалась в ошибке WP Cron (крона). Месяца четыре назад я устанавливал плагин, который запрещает обновляться движку, темам и плагинам. Первым звонком по моим пониманием, были ошибки в серверных логах сайта адресованные wp-cron.php. Ошибка заключалась в выделении памяти на процесс, а точнее нехватки памяти. Когда я вспомнил про эту ситуацию, то сразу обратил внимание.
Что мне помогло:
- Я установил плагин WP Crontrol — планировщик задач wp cron. Советую установить его сразу, очень хорошее решение.
- После установки, я увидел картину в пиковую нагрузку из примерно 900 идентичных событий, которые как я понимаю касаются изображений.
Самое простое решение обнулить все события wp cron до изначального состояния, делается это в functions.php. Достаточно вставить в самом начале файла под
В результате все 900 событий пропали, сайт начал спокойно работать. Серьезных нагрузок на сервер и долгого ответа больше нет. Единственное от чего мне пришлось избавиться, это от запрета на обновление. После этого все проблемы решились. Вот как выглядят показатели нагрузки на данный момент:
Надеюсь эта статья Вам пригодиться и поможет. Если возникнут вопросы пишите в комментариях или в личку.
Многие владельцы сайтов на WordPress задаются вопросами: «Почему мой сайт создает большую нагрузку на хостинг? ». И если одна половина из этих вебмастеров виноваты сами (большое количество ненужных плагинов, плохая оптимизация), то остальная половина действительно не может понять, в чем же дело.
Итак, краткая инструкция для второй половины, как уменьшить нагрузку на хостинг и дополнительно защитить свой сайт на WordPress от взлома.
1) Закрываем xmlrpc.php
xmlrpc.php - это пожалуй самый ненужный файл на сайте, но при этом он часто используется для взлома сайта и создании нагрузки на него.
В файл .htaccess на вашем сайте (в корне) добавляем следующее:
Кроме этого, можно зайти в файл функции темы functions.php и вставить следующий код:
Add_filter("xmlrpc_enabled", "__return_false");
Теперь не забудьте удалить следы данной функции. Заходим в файл header.php вашей темы и удаляем строчку кода, которая содержит pingback и xmlrpc.php. Как правило эта строчка выглядит так:
2) Закрываем или ограничиваем админку
Второй причиной высокой нагрузки является подбор паролей. Хакеры пытаются взломать вашу админку, создавая тонны запросов. Ставим дополнительную защиту через тот же .htaccess файл.
2.1) Если вы единственный админ сайта с постоянным IP адресом:
Создаем в папке wp-admin .htaccess файл и вставляем в него:
Order deny,allow deny from all allow from xxx.xxx.xxx.xxx
Вместо Х пишем ваш IP адрес. В итоге, в админку сможете зайти только вы и никто больше. Даже попытаться не смогут.
2.2) Если вас не устраивает предыдущий вариант, вы просто можете дополнительно защитить вашу админку (без плагина):
В файл .htaccess в корне сайта вставляем следующее:
Сайт.ру - меняем на свой.
Создаем в корне сайта (там же где.htaccess) файл .htpasswd
В этом файле будет содержаться дополнительный логин и пароль. Данная защита осуществляется на уровне сервера, поэтому она довольно надежна. Логин и пароль желательно ставить отличный от логина и пароля на сайте.
Открываем файл .htpasswd и вставляем следующую строку:
Login:$apr1$bHEXXPPA$zhrhn9vOOr/sdsdi3
Где Login - это ваш логин, а после ваш пароль в специальном зашифрованном виде.
Чтобы сгенерировать свой пароль в таком виде, можно воспользоваться различными онлайн-сервисами, к примеру таким: htaccesstools.com .
В итоге вы получаете готовую строчку (зашифрованный пароль), которую нужно вставить в .htpasswd
Как уменьшить нагрузку сайта на вордпрессе на хостинг и оптимизировать базу данных?
Начал задаваться этим вопросом после того, как служба поддержки хостинга Таймвеб написала мне, что мои сайты (их на этом хостинге размещено 10 штук) оказывают чрезмерную нагрузку на центральные процессы хостинга и на базу данных. Повышенная нагрузка была связана частично с ddos-атакой на один мой сайт, ну и в дополнении с тем, что я размещаю сайты на этом хостинге давно уже (более 1,5 года), а никакие работы по очистке мусора с и по оптимизации баз данных не проводил. А ведь сайт можно в некоторой степени сравнить с компьютером. Если не очищать его от ненужных файлов, кряков и прочей лабуды, то компьютер будет со временем поедать и требовать больше ресурсов, что приведет к замедлениям в его работы, частому зависанию. Поэтому нужно заботливо относиться к своим сайтам и периодически проводить действия по оптимизации их работы.
Как снизить нагрузку вордпресса на хостинг и оптимизировать базу данных (MySQL)?
Я провел небольшие действия (о которых расскажу далее), которые позволили мне в результате существенно уменьшить нагрузку на CPU хостинга. Если говорить обобщенно, то удалось снизить нагрузку на CPU с 30-40 до 0,34 – 0,50, а нагрузка на базу данных уменьшить с 90 до 64-70.
В результате проведенных действий по оптимизации базы данных (MySQL) – ее размер удалось уменьшить с 227 мб до 41 мб. Как видим – удалось добиться существенных показателей. А что для этого было сделано?
Оказывает, что любые действия, проводимые в вордпрессе (будь то публикация новой статьи, будь то просто добавление нового плагина и прочее), оказывают какое-то воздействие на базу данных, увеличивая ее в размерах. А чем больше ее размеры, больше различных файлов в ней, находящихся в беспорядочном порядке – тем больше идет нагрузка на процессы хостинга. Поэтому проведя работу по оптимизации базы данных можно существенно сократить эти нагрузки.
Для оптимизации базы данных понадобиться установить и активировать плагин — Optimize DB (о том, как устанавливать плагины читать ). Далее идете в раздел «Инструменты» — находите строчку «Optimize DB» и переходите по ней. Теперь для оптимизации базы данных на вашем сайте остается только нажать на кнопку «Optimize Now».
Вот такие простые действия оптимизируют вашу базу данных на вордпрессе (так сказать упорядочивают в ней хаос и раскладывают все по полочкам).Чтобы работа этого плагина в дальнейшем не создавала дополнительную нагрузку – нужно его просто выключить. Для оптимизации базы данных на вордпрессе раз в неделю или раз в месяц заходите в раздел с плагинами, активизируйте плагин Optimize DB и проводите оптимизацию MySQL (это и есть база данных). А после снова отключайте его.
Но я не ограничился для снижения нагрузки на хостинг только работой с плагином Optimize DB. Была проведена существенная работа по борьбе со спамом. Особенно много спама накопилось на нескольких сайтах (в сумме свыше 6 тыс. штук). Говоря про спам – я имею в виду комментарии спамного характера, большое количество которых также нагружает хостинг. Удалил много комментариев ожидающих проверки (точнее, чтобы полностью их удалить – отправлял их первоначально в корзину, а потом корзину очищал), также очищал папку со спамом. В в последнее время мне существенно помогает плагин «Invisible Captcha». Благодаря нему спам мгновенно отправляется в папку со спамом, а оттуда все спамные комментарии можно мгновенно удалить, очистив эту папку.
Посоветовал бы установить еще плагин «WP Super Cache» (если он не установлен), активировать, и включить кэширование. Особенно полезен он будет, если на ваши сайты уже стало заходить много посетителей. В процессе работы я установил его еще на парочку сайтов. Благодаря кэшированию нагрузка на хостинг также уменьшается.
Вот такая была проведена работа над 10 сайтами, которая заняла у меня около 2 часов. Но своего я добился – удалось существенно снизить нагрузку вордпресс на хостинг.
Также стоит отметить, что чем больше на сайте на вордпрессе активировано разных – тем больше нагрузка. Поэтому используйте только те плагины, которые вам необходимы и выключайте те, которые не используете.
В этой статье я хочу рассказать о способах оптимизации блога WordPress для снижения его нагрузки на сервер . Рано или поздно всем приходится задумываться над этой проблемой. Так как движок WordPress основан на PHP и MySQL, то каждый раз при каждом обращении к страницам сайта он создает определенную нагрузку на сервер. И чем больше этих обращений, тем больше нагрузка. Так как большинство из нас использует обычный хостинг, то всем приходится подчиняться определенным правилам, одним из которых есть ограничение нагрузки на сервер. Исходя из этого, есть смысл оптимизации своего блога WordPress.
Итак, для начала давайте разберем принцип работы движка на основе PHP+MySQL.
Когда пользователь обращается к какой-то странице сайта, на сервере (при помощи специального серверного языка или просто PHP) идет обращение к так называемой базе данных, которая содержит в себе всю информацию. Затем нужная информация вытаскивается и формируется статическая HTML страница.
Все довольно просто и очень эффективно. Это позволяет нам избежать огромного количества статических HTML страниц, что значительно уменьшает объем занимаемого сайтом места. Также существует множество других плюсов, но есть и свои минуса, одним из которых есть нагрузка на сервер. Есть множество способов ее уменьшения. Я расскажу о трех из них, которыми пользуюсь сам. Они показали неплохие результаты, поэтому есть смысл в их использовании.
Оптимизация блога WordPress при помощи кэширования страниц. Плагин Hyper Cache и его настройка.
Оптимизация WordPress при помощи данного метода состоит в том, что при обращении к страницам сайта, как обычно, генерируется статическая html страница. Разница лишь в том, что она сохраняется в КЭШе. При следующем обращении к этой странице вместо того, чтобы генерироваться заново, она просто берется из КЭШа. Это позволяет значительно уменьшить число запросов к базе данных и как следствие уменьшить нагрузку на сервер.
Итак, первым делом нам нужно скачать и установить плагин Hyper Cache. Для этого переходим на официальный сайт WordPress и скачиваем последнюю версию плагина. Далее копируем файлы в папку \wp-content\plugins\ и активируем плагин через административную панель. Для этого переходим в административную панель — плагины и активируем Hyper Cache.
После установки и активации плагина, переходим к его настройке. Точнее для начала нам нужно активировать кэширование в самом WordPress. Для этого нам придется редактировать файл wp-config.php и вставить в него строку
Define("WP_CACHE", true);
Лучше это делать ближе к концу файла, но не дальше строк
If (!defined("ABSPATH")) define("ABSPATH", dirname(__FILE__) . "/");
Затем нам необходимо соединиться с сервером и выставить права доступа 777 для папки wp-content. В принципе можете поставить эти права на саму папку с КЭШем. После этого переходим в административную панель\параметры\Hyper Cache и активируем его. Затем переходим к самим настройкам кэширования.
- Время жизни кэшированных страниц – устанавливаете время, которое будет существовать страница в КЭШе. То есть после обращения к статье WordPress кэширует эту страницу и сохраняет ее. От значения, которое вы здесь установите, будет зависеть время существования этой страницы, до ее удаления или обновления. Можете ставить по своему усмотрению. Обычно чем дольше, тем лучше.
- Автоочистка – данная функция проводит проверку КЭШа на наличие записей с истекшим сроком. Если такие находятся, то они удаляются. Благодаря этому вы можете быть спокойны, что у вас не будет накапливаться мусор, который может весить довольно много, что в свою очередь приведет к уменьшению свободного пространства на диске. Значение можете подбирать индивидуально. Вполне подойдет 1440 минут.
- Как очищать кэш – ставим значение «Single pages». На мой взгляд, это оптимальный вариант. В этом случае при внесении изменений кэш будет обновляться только для тех страниц, которые были редактированы. Остальные же останутся нетронутыми. При большой посещаемости это имеет смысл, так как если бы каждый раз, когда вы редактировали статью, очищался бы весь кэш, то это бы создало огромную нагрузку на сервер.
- Не кэшировать домашнюю страницу – можете поставить галочку, если не хотите, чтобы сохранялась главная страница. Данная опция имеет смысл, если у вас очень часто обновляется главная страница вашего блога. В принципе ставим по желанию. Лично у меня эта опция включена.
- Исключить URI – сюда можно вписать адреса страниц, которые вы хотите исключить с КЭШа.
Это были основные настройки плагина Hyper Cache. Для того, чтобы проверить его работоспособность, заходим на наш сайт как незарегистрированный пользователь и смотрим исходный код страницы. В конце должна присутствовать такая строка.
Если она есть, то плагин работает нормально.
Снижение нагрузки на сервер за счет кэширования запросов к базе данных.
Для этого можно использовать специальный плагин DB Cache Reloaded . Он кэширует запросы и направляет их не в базу данных, а в кэш, доступ к которому более быстрый. За счет этого уменьшается нагрузка на сервер и увеличивается скорость генерации страниц, что, в свою очередь, увеличивает скорость загрузки самого блога.
Настройки этого плагина очень просты и приводиться не будут. Там все интуитивно понятно. Единственное, что могу предложить, это добавить в footer.php код, который будет выводить информацию о количестве запросов к базе и время загрузки страницы.
Для этого открываем на редактирование файл footer.php и где-то в конце добавляем код
queries in seconds.
Приведенный выше вариант будет выводить информацию о количестве обращений к БД и времени загрузки страницы. Замечу, что информация будет видна только вам. То есть будет выводиться только тогда, когда вы авторизированны на сайте. Выглядеть это будет примерно так:
Естественно можно поиграть со стилями, перевести «queries in» и «seconds», но это по желанию. Лично меня и так все устраивает.
Оптимизация шаблона WordPress
Оптимизация шаблона или темы сводится до уменьшения количества обращений к базе данных. Так как шаблоны создаются универсальными, то разработчики стараются все автоматизировать. Все это делается для удобства пользователей. Но если вы уже разобрались с темой, которую будете использовать, то можно уже начинать ее оптимизировать. Весь смысл состоит в том, чтобы заменить стандартные PHP кода с обращениями к базе на статичные. Проделывать такое мы будем в двух файлах – шапке сайта и футере. Начнем с первого.
Оптимизация header.php
1. Находим код
и меняем его на название своего блога. У меня это
Сайт - создание и продвижение сайтов, блогов, заработок на сайте.
2. Код, отвечающий за вывод описания, заменяем на статический.
3. Строка, отвечающая за вывод кодировки.
; charset=" />
Поскольку мы знаем, что кодировка WordPress UTF8, то можем видоизменить данный код и сделать его таким:
4. Удаляем строку, которая отвечает за вывод информации о вашей версии WordPress.
" />
Это нужно сделать для улучшения безопасности блога, так как именно эта информация является опасной и может сообщить злоумышленникам то, что им знать не нужно. Тем более если вы используете более раннюю версию движка, то данное изменение вам необходимо.
5. Заменяем путь к таблице стилей вашего шаблона на статичный.
" type="text/css" media="screen" />
После модификации будет иметь примерно такой вид:
6. Меняем путь к RSS ленте на статический.
RSS Feed" href="" />
После изменения будет выглядеть вот так:
7. Также можно изменить путь до Pingback (рассылка, которая отправляет сведенья по всем адресам, упомянутым в этой заметке).
" />
Заменяем на
Оптимизация файла footer.php
В принципе здесь, по большому счету, можно оптимизировать только вывод копирайта. Для этого код
заменяем на свой текст. У меня это
- «Оптимизация WordPress за счет уменьшения количества обращений к данным »
На этом я заканчиваю данную статью. Если у вас остались какие-то вопросы, вы всегда сможете задать их в комментариях.
На этом все. Удачи вам и успехов в оптимизации сайтов.
