Тормозит админка wordpress как исправить ошибки
Перейти к содержимому

Тормозит админка wordpress как исправить ошибки

  • автор:

Почему так тупит админка WordPress?

Чистая установка вп на довольно мощный VPS на дефолтной теме на абсолютно пустом сайте дает такую картину: любой материал, который редактируется в админке (страница, обычный пост или же кастом — без разницы), при сохранении тупит 2-3 секунды независимо от настроек ВП (даже на локальном сервере).
С каждым новым установленным плагином тупняк увеличивается на 1-2 сек.
Поставил чистый плагин Woocommerce — вообще беда. 6-8 секунд пересохраняется товар (даже если текст не менять — просто добавить пробел в заголовок). А с нужными мне плагинами для магазина всё это дело превращается в 12-15 секунд сохранения. Товаров очень много, такие задержки просто непростительны.
Пробовал и оптимизировать тему (даже дефолтную подчищал), и кеширующие плагины — толку нет.
В файрбаге всегда показывает долгую реакцию на admin-ajax.php. Эффекта от установки сайта на локальный сервер тоже нет. От разных версий вп тоже толку ноль.
На фронтенде со всей графикой с помощью сжатия и кеш-плагинов добиваюсь 2-3 сек загрузки. Жестокий тупняк — только в админке.

  • Вопрос задан более трёх лет назад
  • 6212 просмотров

Комментировать
Решения вопроса 0
Ответы на вопрос 4

HeadOnFire

Игорь Воротнёв @HeadOnFire
PHP, Laravel & WordPress Evangelist

1. Перейти на Nginx, последняя версия ветки mainline
2. Перейти на последнюю версию PHP5-FPM с OPcache
3. Перейти на MariaDB 10
4. Установить Memcached, модуль php5-memcached (c буквой d в конце, НЕ php5-memcache)
5. Для профита от п.4 установить плагин Memcached Redux

Можно в обратном порядке — Memcached, MariaDB, свежий PHP c OPcache, потом уже Nginx. Кроме того, неплохо бы протюнить настройки MySQL (или MariaDB) — особенно кеши. Но для этого надо проработать в штатном режиме хотя бы недели две, чтобы накопилась статистика. Лучше месяц.

У вас, скорее всего, затык в связке php-mysql, запросы обрабатываются долго. Попробуйте поставить плагин Query Monitor и посмотреть узкие места.

Ответ написан более трёх лет назад
Нравится 2 3 комментария
Mr Crabbz @Punkie Автор вопроса

Пробовал перейти на nginx — испытываю проблемы с пермалинками. На всех страницах, кроме главной получаю ошибку 404. Не подскажете решение?

HeadOnFire

Игорь Воротнёв @HeadOnFire
@Punkie Легко подскажу 🙂 Все, что нужно:
location / < try_files $uri $uri/ /index.php?$args; >
Здесь подробно: wiki.nginx.org/WordPress
Mr Crabbz @Punkie Автор вопроса
Большое спасибо! Попробую.
Senior Ruby on Rails developer

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

Ответ написан более трёх лет назад
Нравится 1 1 комментарий

HeadOnFire

Игорь Воротнёв @HeadOnFire

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

Тормозит адмика в WordPress

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

Плагины которые могут помочь

В интернете везде советуют поставить эти плагины и посмотреть в них что мешает сайту нормально работать. Я так и поступил.

Health Check & Troubleshooting

PHP Compatibility Checker

Но ничего существенного там не было. Только ошибка :

Ваш сайт не смог подключиться к WordPress.org по 198.143.164.251, и вернул ошибку: cURL error 28

В первую очередь установил cURL на север где лежит сайт, но это не помогло. Перепробовал кучу советов из интернета, но ничего не помогало и в конце концов нашел в справке wordpress пожелание использовать google dns. Ради интереса меняю провайдерские DNS на гугловские и о чудо — WP залетал! Самое интересно что на этом же сервере у меня было куча других сайтов (не вордпресс) и у них никаких проблем не было и со старыми DNS.

DNS которые помогли

Файл /etc/hosts

Если у вас сайт лежит на собственном сервере который частично закрыт фаерволом, то желательно ещё добавить запись в файлик /etc/hosts запись о нашем сайте например так:

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

Ваш сайт не может выполнять петлевые запросы

  • ← MIUI 9 Перестал подходить графический ключ и отпечаток пальца.
  • USB модем в linux →

WordPress тормозит! Как быстро найти причину?

Хочу поделиться с вами информацией на тему производительности сайта на wordpress. Не всегда бывает просто узнать, почему он внезапно начал тормозить. В общем случае нужно запустить профилирование php чем то наподобие xhprof или xdebug и смотреть, в чем проблема. Но это трудный путь, для того чтобы по нему пройти, необходимы знания и небольшая работа с кодом сайта. Есть путь проще с помощью wp-cli и profile-command.

Углубленный онлайн-курс по MikroTik

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном онлайн-курcе по администрированию MikroTik. Автор курcа – сертифицированный тренер MikroTik Дмитрий Скоромнов. Более 40 лабораторных работ по которым дается обратная связь. В три раза больше информации, чем в MTCNA.

Содержание

Введение

В случае использования wp-cli, специальные знания не нужны. В код wordpress тоже лазить не надо. Нужен будет только консольный доступ к web серверу по ssh. WP-CLI — это по сути набор php скриптов для работы с сайтом на worpdress через командную строку. Многое из того, что вы делаете через админку сайта можно сделать с его помощью. Например, обновить или установить плагин. С помощью wp-cli этот процесс можно заскриптовать и автоматизировать.

В том числе через wp-cli и дополнение к нему profile-command можно выполнить профилирование wordpress и понять, что и как влияет на скорость загрузки и работы сайта. Я впервые познакомился с этим инструментом, когда внезапно у меня начала тормозить админка одного из сайтов на wordpress. Она грузилась по 10-15 секунд и невозможно было понять, с чем именно это связано. С помощью profile-command я смог определить, какой плагин замедлял работу сайта.

Конкретно для подобного случая, когда тормозит админка worpdress из-за какого-то плагина, я и рассмотрю работу с wp-cli/profile-command. Начнем с того, что установим wp-cli на сервер.

Установка wp-cli

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

# cd ~ # curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar

Делаем исполняемым и копируем в системную директорию, откуда он будет вызываться.

# chmod +x wp-cli.phar # mv wp-cli.phar /usr/local/bin/wp

Проверяем, все ли в порядке:

# wp --info

Установка wp-cli

У меня это тестовый web сервер на базе Centos. Я подключился под root. Дальше нам нужно будет все делать от имени пользователя, под которым работает web сервер. В моем случае это стандартный пользователь nginx. Проверим работу под ним.

# sudo -u nginx wp --info sudo: wp: command not found

Для этого пользователя не прописан path=/usr/local/bin, поэтому надо писать полный путь к скрипту.

# sudo -u nginx /usr/local/bin/wp --info

Проверка wp-cli на wordpress

Теперь выполним установку пакета profile-command.

# sudo -u nginx /usr/local/bin/wp package install git@github.com:wp-cli/profile-command.git

Если у вас по-умолчанию для работы php скрипта выделяется менее 256мб памяти, то скорее всего получите ошибку:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 9437184 bytes) in phar:///usr/local/bin/wp/vendor/composer/composer/src/Composer/Repository/ComposerRepository.php on line 588 Reverted composer.json. WP-CLI ran out of memory. Please see https://bit.ly/wpclimem for further help.

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

# sudo -u nginx php -d memory_limit=512M /usr/local/bin/wp package install git@github.com:wp-cli/profile-command.git

Wp-cli хранит все настройки и пакеты в домашней директории пользователя, в папке .wp-cli. У пользователя должны быть права на ее создание. В моем случае пользователь nginx имеет домашнюю директорию /var/cache/nginx, в которую у него нет прав на запись. В итоге, папку .wp-cli я создал вручную и назначил ей права пользователя nginx.

# mkdir /var/cache/nginx # chown -R nginx. /var/cache/nginx # chmod -R 0700 /var/cache/nginx

После этого установка модуля прошла без ошибок. По сути, были просто скачаны его исходники в директорию /var/cache/nginx/.wp-cli/packages/vendor/wp-cli/profile-command.

У нас все готово для профилирования wordpress, чтобы понять, из-за чего он может тормозить. Давайте разберем, как это сделать.

Смотрим, из-за чего тормозит wordpress

Запускаем профилировщик, указывая ему путь к директории с сайтом wordpress.

# sudo -u nginx /usr/local/bin/wp profile stage --path=/web/sites/serveradmin.ru/www

Проверяем время загрузки wordpress по этапам

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

Мы видим 3 этапа загрузки wordpress с указанием затраченного времени на каждый этап. Что они значат:

  1. bootstrap — по сути это сам wordpress и есть. Тут загружаются плагины, темы и хуки движка.
  2. main_query — формирование на основе запроса страницы основного класса worpdress — WP_Query.
  3. termplate — здесь wordpress на основе данных из wp_query определяет тему и рендерит вывод.

Можно выбирать набор столбцов для вывода. Например, можно оставить только название этапа, время выполнения и использование кэша.

# sudo -u nginx /usr/local/bin/wp profile stage --fields=stage,time,cache_ratio --path=/web/sites/serveradmin.ru/www

Фильтр по столбцам

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

# sudo -u nginx /usr/local/bin/wp profile stage bootstrap --path=/web/sites/serveradmin.ru/www

Профилирование wordpress

Видим список хуков. Смотрим информацию по хукам plugins_loaded и init.

# sudo -u nginx /usr/local/bin/wp profile hook plugins_loaded --fields=callback,location,time,cache_ratio,request_time --path=/web/sites/serveradmin.ru/www

Какой плагин тормозит в wordpress

Если какой-то плагин wordpress тормозит, вы увидите это в таблице. В моем случае явного аутсайдера нет, так как на сайте все в порядке. Иногда бывает так, что какой-то плагин вообще ломает работу сайта так, что даже профайлер не работает. Можно исключить этот плагин из работы и протестировать скорость запуска wordpress без него. Делается это так.

# sudo -u nginx /usr/local/bin/wp profile hook plugins_loaded --fields=callback,location,time,cache_ratio,request_time --path=/web/sites/serveradmin.ru/www --skip-plugins=wpforo

Можно сразу отсортировать вывод по определенным столбцам. Например, по времени исполнения.

# sudo -u nginx /usr/local/bin/wp profile hook init --fields=callback,location,time,cache_ratio,request_time --path=/web/sites/serveradmin.ru/www --orderby=time --order=DESC

Список всех плагинов со временем загрузки каждого

И так далее. Тут можно детально разобрать производительность wordpress и понять, из-за чего он тормозит.

Заключение

Не понравилась статья и хочешь научить меня администрировать? Пожалуйста, я люблю учиться. Комментарии в твоем распоряжении. Расскажи, как сделать правильно!

Вот таким простым способом можно выяснить, из-за чего тормозит WordPress. При чем вам не нужно ничего устанавливать на сервер, кроме дополнительных php скриптов. В сам код сайта тоже лазить не надо. Простые ситуации очень быстро и просто решаются с помощью wp-cli. С помощью него можно быстро выяснить, из-за какого плагина не работает сайт. Обычно я иду в директорию /wp-content/plugins и начинаю по очереди отключать плагины, переименовывая директории. С помощью wp-cli/profile-command это сделать проще и быстрее.

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

Онлайн-курс по устройству компьютерных сетей.

На углубленном курсе «Архитектура современных компьютерных сетей» вы с нуля научитесь работать с Wireshark и «под микроскопом» изучите работу сетевых протоколов. На протяжении курса надо будет выполнить более пятидесяти лабораторных работ в Wireshark.

Ускоряем админку WordPress — отключаем агрессивную проверки обновлений

Это, на мой взгляд, обязательная фитча для всех сайтов на WordPress, как принято говорить — маст хэв. Почему? Потому что проверка обновлений должна идти фоном и никак иначе, за очень редким исключением! Давайте разберемся что к чему.

Как полностью отключить авто-обновления для ядра, тем, плагинов, читайте в отдельной статье: Авто-обновления в WordPress.

Причина тормозов в админке

  • На странице Консоль Обновления — раз в минуту.
  • На странице Плагины или Внешний вид > Темы — раз в час.
  • На любой странице в админке — раз в 12 часов (два раза в день).

Кроме того, эти проверки срабатывают во время события ‘admin_init’ , а значит при AJAX запросах. Несмотря на то что это происходит раз в пол дня, все же неприятно когда кто-то будет ловить AJAX запрос с задержкой в 3 секунды. Кроме того, такое поведение для AJAX запросов работает и во фронтэнде, а это уже совсем нехорошо.

Фронт и админка

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

В админке происходит «агрессивная проверка» не фоном, а прям при генерации страницы. Сделано так для того, чтобы при заходе в админку мы сразу, в меню видели что есть обновления. Если была бы фоновая проверка, то чтобы увидеть наличие обновлений нам нужно было бы зайти на страницу еще раз. Если сравнивать этот минус с тормозами, я однозначно выбираю его!

Тормоза и объектное кэширование

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

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

Решение (отключаем тормоза)

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

Этот код полностью отключает «агрессивную» проверку обновлений в админке. Но не трогает проверку обновлений по крону. Также, если нужно проверить наличие новых версий прямо сейчас, то заходим на страницу Консоль > Обновления — там «агрессивная» проверка не отключается и срабатывает каждую минуту.

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

 Updates" page. * * @see https://wp-kama.ru/filecode/wp-includes/update.php * @author Kama (https://wp-kama.ru) * @version 1.1 */ if( is_admin() ) < // disable update checks when entering the admin panel. remove_action( 'admin_init', '_maybe_update_core' ); remove_action( 'admin_init', '_maybe_update_plugins' ); remove_action( 'admin_init', '_maybe_update_themes' ); // disable update checks when entering a special page in the admin panel. remove_action( 'load-plugins.php', 'wp_update_plugins' ); remove_action( 'load-themes.php', 'wp_update_themes' ); // leave forced checking when entering the updates page. //remove_action( 'load-update-core.php', 'wp_update_plugins' ); //remove_action( 'load-update-core.php', 'wp_update_themes' ); // leave forced checking when entering the "Update/Install Plugin" or "Update/Install Theme" page - it doesn't interfere. //remove_action( 'load-update.php', 'wp_update_plugins' ); //remove_action( 'load-update.php', 'wp_update_themes' ); // don't touch the cron event, it will be used to check for updates - everything is fine here! //remove_action( 'wp_version_check', 'wp_version_check' ); //remove_action( 'wp_update_plugins', 'wp_update_plugins' ); //remove_action( 'wp_update_themes', 'wp_update_themes' ); /** * disable the need to update the browser in the console - we always use top browsers! * this check happens once a week. * @see https://wp-kama.ru/function/wp_check_browser_version */ add_filter( 'pre_site_transient_browser_'. md5( $_SERVER['HTTP_USER_AGENT'] ), '__return_empty_array' ); >

Плагин

По коду из этой статьи был создан плагин: Disable Aggressive Updates.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *