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

Установите и активируйте плагин Debug Objects

Мы воспользуемся плагином Debug Objects, чтобы найти и расшифровать запросы к базе данных, необходимые для отображения вашего сайта. Debug Objects покажет подробную разбивку запросов каждой страницы сайта. Только вы можете видеть этот вывод после входа в систему в качестве администратора. Посетители не будут видеть отладочную информацию.

Чтобы установить плагин, перейдите в Консоль WordPress, в меню слева выберите «Плагины», а затем Добавить новый. В окне поиска введите «debug objects» и нажмите клавишу ввода.

На странице результатов поиска нажмите кнопку «Установить»:

Установка плагина Debug Objects
Установка плагина Debug Objects

После установки плагина активируйте его.

Как вариант Debug Objects можно скачать прямо из репозитория WordPress и загрузить его на сервер в wp-content/plugins. Затем активируйте его на странице плагинов в консоли администратора WordPress.

Отключите Xdebug

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

Настройте Debug Objects, чтобы проанализировать SQL-запросы

Сначала добавьте эту строку в файл wp-config.php (находится в основном каталоге с установленным WordPress):

define( 'SAVEQUERIES', TRUE );

Теперь перейдите в Инструменты -> Debug Objects и отключите все параметры, кроме DB Query:

Настройка объектов отладки
Настройка объектов отладки

Прокрутите это окно вниз и щелкните кнопку Сохранить.

Проверьте отладочный вывод

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

Ссылка на объекты отладки
Ссылка на объекты отладки

Вы увидите три вкладки с отладочной информацией:

Вывод объектов отладки в трех вкладках
Вывод объектов отладки в трех вкладках

Как прочесть и расшифровать отладочный вывод

Эти три таблицы содержат много данных, но только их часть важна для нас и относится к плагину WPML. В общем, нас интересуют две вещи:

  • Очень медленные запросы – иногда большинство проблем быстродействия появляются в результате нескольких очень длительных запросов
  • Ряд повторяющихся запросов – в других случаях нет очень медленных запросов, а есть множество быстрых запросов, которым для завершения совокупно требуется много времени

Обнаружение медленных запросов

Перейдите в первую вкладку Запросы к БД и поищите там самые медленные запросы. Плагин Debug Objects упрощает эту задачу, выделяя оранжевой рамкой запросы, для завершения которых требуется свыше 0,5 мс:

Медленные запросы
Медленные запросы

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

Проверьте, является ли плагин WPML источником запроса

Скопируйте медленный запрос (Ctrl+C) и выберите вторую вкладку Запросы плагинов к БД. Вы увидите несколько таблиц с запросами, упорядоченными по именам и файлам плагинов, через которые проходили запросы. Если плагин WPML участвовал в выполнении этого запроса, он должен быть в соответствующей таблице.

Нажмите на клавиатуре Ctrl+F, а затем Ctrl+V, чтобы вставить скопированный запрос.

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

Проверьте каждый результат поиска, и нет ли его в таблице под одним из плагинов WPML. Если есть, то запишите:

  • имя плагина
  • файл, в котором выполнен запрос
  • номер строки в этом файле (первый столбец таблицы)

Подробности запроса
Подробности запроса

Распространенные запросы из WPML и других плагинов и тем

Некоторые из запросов проходят через другие плагины и/или темы, а также плагин WPML. Например, Перевод строк WPML предоставляет возможность переводить строки ядра WordPress, темы и всех других плагинов. Если вы увидели плагин String Translation в списке запросов к БД, это означает, что WPML нужно перевести много различных строк на вашем сайте.

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

Сообщение о своих результатах через технический форум WPML

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

  • Медленный запрос и его длительность до выполнения.
  • Где/можно ли найти этот запрос во второй вкладке журнала отладки. Содержится ли он в плагине WPML и, если да, то задействованные файлы и номера их строк.
  • Где/можно ли найти этот запрос в третьей вкладке, а также имя файла и номер строки.

Скопируйте содержимое каждой вкладки и отправьте его нам при помощи Pastebin.

Для этого:

  1. Перейдите на форум технической поддержки WPML и начните новое обсуждение. Опишите обнаруженную проблему быстродействия и место, где мы также сможем ее увидеть.
  2. Откройте первую вкладку результатов Debug Objects
  3. Выделите содержимое этой вкладки. Обязательно включите все из «запросов», включая раздел «ошибки» и весь список запросов.

    Выбор всех запросов
    Выбор всех запросов

  4. Скопируйте (ctrl+C) выделенное
  5. Перейдите на pastebin.com, вставьте (ctrl+V) выделенный фрагмент в текстовую область и щелкните кнопку «Отправить».

    Вставка в Pastebin
    Вставка в Pastebin

  6. Скопируйте URL-адрес из адресной строки своего браузера.

    Копирование URL-адреса Pastebin
    Копирование URL-адреса Pastebin

  7. Вставьте этот URL-адрес Pastebin в поток поддержки.
  8. Повторите шаги 2–6 для содержимого двух других вкладок.

Теперь сотрудники нашей Службы поддержки будут знать, к какому сайту относится ваше обращение, и какая страница медленно грузится. Они смогут увидеть весь список выполненных запросов и помогут вам найти причину проблемы. Если это WPML, мы найдем решение (и включим исправление в следующую версию). Если это тема или другие плагины, мы обратимся к другим разработчикам и сделаем все возможное, чтобы у вас все работало без заминок.


Приложение: Отключение Xdebug

Xdebug – расширение PHP для отладки проблем в ядре. При правильном использовании оно также поможет проанализировать источник проблем с быстродействием.

Во время работы Xdebug значительно увеличивает нагрузку на сервер, так как ему необходимо записать происходящее в режиме реального времени. По этой причине Xdebug НИКОГДА не должен работать во время оценки быстродействия. Если Xdebug будет работать во время оценки быстродействия, вы получите совершенно неправильные показатели. Причиной большей части нагрузки в отчете будет Xdebug, а не код, оценку быстродействия которого вы хотите выполнить.

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

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

Убедиться в том, что он выключен, можно с помощью вывода phpinfo().

Xdebug в выводе файла phpinfo
Xdebug в выводе файла phpinfo (плохо для оценки быстродействия)

Если вы хотите выключить xdebug, удалите или раскомментируйте его в php.ini или своем conf.d/xdebug.ini:

zend_extension=xdebug.so

Удалите, а не добавьте строку вверху!

Так должна выглядеть информация phpinfo при отключенном Xdebug:

Информация phpinfo при отключенном Xdebug: (хорошо для оценки быстродействия)
информация phpinfo при отключенном Xdebug: (хорошо для оценки быстродействия)

Если в ней нет никаких ссылок на Xdebug, он точно выключен.

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