С какими нагрузками можно справить вордпресс. Как уменьшить нагрузку на сервер и ускорить WordPress с помощью Memcached

Если вы получили уведомление о превышении лимита на использование CPU, это означает, что потребление ресурсов процессора вашим аккаунтом превысило суточную норму , установленную тарифным планом.

В письме от провайдера, как правило, сообщаются:

• пункт Договора/Правил, который был нарушен;
• суть нарушения;
• текущее состояние аккаунта;
• предлагаемые меры, которые клиенту необходимо выполнить для возобновления предоставления услуги.

Выявляем причину повышения нагрузки на хостинг

Первое, что необходимо сделать, это понять основную причину, по которой возрасла нагрузка на ЦП.

1. Нагрузка на CPU из-за неоптимальной работы скриптов или неоптимизированной базы данных

Оптимизация CMS: Отключите неиспользуемые и тяжелые плагины CMS, настройте кэширование посредством CMS (для WordPress например можно использовать WP Super Cache или WP-cache.com).

Оптимизация базы данных: Запросы к MySQL, которые выполняются более 0,5 секунд, часто создают избыточную нагрузку на дисковую систему сервера и на его процессор. Проверьте логи медленных запросов к БД (можно запросить у хостера) и выполните оптимизацию структуры БД, а также почистите её от неактуальной информации.

2. Избыточное число запросов к сайту

Повышение нагрузки на CPU может быть свидетельством большого количества запросов от поисковых и иных роботов, или, особенно при скачкообразном резком росте - свидетельством DDOS-атаки или Brute-Force атаки.

Проверка источников запросов: откройте лог-файл со статистикой запросов по User-Agent - из него вы сможете понять, какие роботы с какой периодичностью обращаются к вашему сайту (например YandexBot, bingbot). В логах со статистикой по IP-адресам проверьте, не идёт ли с каких-либо IP огромный поток обращений (если да, то возможно это атака на сайт). Узнать больше информации про IP (кому он принадлежит) можно при помощи сервисов Whois.

Настройка ограничения для роботов : Настройте файл robots.txt: установите таймаут обращения роботов к вашему сайту при помощи директивы Crawl-delay:

Для отдельного бота:

User-agent: bingbot Crawl-delay: 10 # задает таймаут в 10 секунд только для бота bingbot

Или сразу для всех ботов:

User-agent: * Crawl-delay: 10 # задает таймаут в 10 секунд для всех поисковых роботов

Настройка ограничений по IP-адресам: Для блокировки доступа по IP добавьте в файл.htaccess, находящийся в корневой папке сайта, следующие строки (в примере ниже блокируем доступ к сайту для IP-адресов 121.123.123.123 и 121.122.122.122):

Order Allow,Deny Allow from all Deny from 121.123.123.123 Deny from 121.122.122.122

3. Реальное увеличение посещаемости ресурса

С развитием сайта посещаемость его растёт, и чем выше посещаемость, тем больше нагрузка на CPU. В случае перехода порога посещаемости в 10000 уникальных посетителей в сутки на обычном виртуальном хостинге сайту будет однозначно тесно и необходимо переносить его на выделенный сервер.

4. Слабый хостинг

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

После проведенного анализа рынка услуг виртуального хостинга был найден наиболее оптимальный вариант по соотношению Цена/Качество. Рекомендуем бесплатно попробовать этот хостинг , и перейти на него (при заказе введите промо-код сайт и получите скидку 10% на услуги хостинга ).

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

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

На этом все. Удачи вам и успехов в оптимизации сайтов.

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

Вконтакте

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

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

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

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