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

Здравствуйте, уважаемые читатели блога сайт. C Наступившими Вас праздниками!

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

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

В общем, за WordPress нужен глаз да глаз. Да, движок бесплатный, при этом профессиональный и попросту чумовой, но излишества всякие нехорошие нет-нет да и проскакивают. Вот. В этот раз взгляд тоже зацепился за «что-то новенькое». Это были три строчки кода (а точнее три служебных гиперссылки) опять же в шапке страницы формируемой WordPress:

Немного погуглив я понял, что «это» появилось в WordPress 4.4 и нужно для чего-то (пока смутно представляю для чего — если в курсе, то поясните). Т.к. «это» появилось недавно, то особо много рецептов удаления нагуглить не удалось, а то, что нашлось, работало как-то кривенько (первая ссылка удалялась, но две другие нет, и вести они стали на ту же страницу, код которой был открыт).

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

Помимо этого в исходном коде был еще и сильно бросающийся в глаза блок:

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

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

Remove_action("wp_head", "print_emoji_detection_script", 7); remove_action("admin_print_scripts", "print_emoji_detection_script"); remove_action("wp_print_styles", "print_emoji_styles"); remove_action("admin_print_styles", "print_emoji_styles"); remove_filter("the_content_feed", "wp_staticize_emoji"); remove_filter("comment_text_rss", "wp_staticize_emoji"); remove_filter("wp_mail", "wp_staticize_emoji_for_email");

Это вариант самого полного отключения поддержки эмодзи в WordPress . Хотите в админке оставьте . Все, после этого наступило приятное чувство чистоты кода от всяко разного.

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

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

Как пришло осознание

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

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

Во всяком случае по срокам и по тому, что проблема не проявляется после удаления кода поддержки эмодзи, можно было сделать определенные выводы. Я их сделал и написал этот пост. Если проблема вылезет опять, то чуть ниже появится P.S. с сожалениями по поводу напрасно потраченного времени (вами на чтение, а мною на написание).

Решение получилось действительно несуразным, по крайней мере глядя с моей, крайне невысокой в умственном плане, колокольни. Где логика? Не знаю, но все равно приятно, что пусть и случайно, но мучивший меня довольно долго технический казус более-менее удачно разрешился. За сим разрешите откланяться. Спасибо за внимание и еще раз с Наступившими праздниками.

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

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

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

Пропало левое меню в админке WordPress после обновления Где скачать WordPress - только с официального сайта wordpress.org
Установка WordPress в деталях и картинках, вход в админку WP и смена пароля Пустая страница при просмотре больших постов (статей) в WordPress
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации
Как войти в админку WordPress, а так же поменять логин и пароль администратора выданные вам при установке движка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Запросов к MySQL Скорость генерации страницы Без скрипта 11.68 MB 31 0,68 С MaxCache 0.82 MB 0 0,00025

Нагрузка на сервер снизилась более чем в 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 идеальное решение.

Вконтакте

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

Вконтакте

Оцените материал: