Тестирование производительности WordPress: воспроизводимое тестирование производительности хостинга

На что отвечает тест производительности WordPress

A Тестирование производительности WordPress Начинается с конкретного вопроса: быстро ли загружается определённая страница при заданных условиях? Для этого браузер загружает HTML, изображения, скрипты и другие ресурсы, а затем отображает страницу. Результат отражает взаимодействие всех этих компонентов, а не только скорость работы хостинг-сервера.

Второй вопрос касается Характеристики отклика под нагрузкой: Как изменяются время отклика и количество ошибок, когда поступают запросы, соответствующие заданному профилю? Один-единственный просмотр страницы не даст ответа на этот вопрос. И наоборот, тест нагрузки HTTP не показывает сразу, как быстро браузер отображает страницу целиком.

В случае публичной статьи в блоге кэш страниц может предоставлять готовый HTML-код; CDN может доставлять ресурсы или ответы ближе к месту измерения. В то же время на результат влияют тема, плагины, изображения и внешние скрипты. О том, какие ещё факторы могут замедлять работу страницы, рассказывается в статье о скрытые факторы, снижающие производительность WordPress.

Чтобы оценить влияние хостинга, полезно задать два сравнительных вопроса. При Сравнение стеков Вы максимально синхронизируете веб-сайт и настройки и фиксируете оставшиеся различия. При сравнении пакетов вы проверяете предлагаемые конфигурации, включая соответствующие кэши и сервисы. Это полезно для принятия решения о покупке, но не позволяет оценить исключительно производительность самого сервера.

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

Понимание показателей браузера и полевых данных

Тест скорости WordPress с помощью Lighthouse дает Фотография лаборатории страницы при определённых условиях измерения. Поэтому в протокол должны включаться данные о профиле браузера, устройстве или эмуляции, сетевом профиле, месте проведения измерений и версии инструмента. Только так впоследствии можно будет оценить, действительно ли два запуска сопоставимы.

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

К важным показателям относится LCP: он описывает, когда загружается самый большой значимый элемент контента, видимый пользователю. CLS фиксирует непредвиденные сдвиги макета во время использования. INP описывает отзывчивость на взаимодействия; для его расчета требуются фактически зарегистрированные взаимодействия, и он не определяется исключительно простым загрузкой страницы.

Отчет Chrome UX (CrUX) предоставляет, при наличии, соответствующие данные Полевые данные на основе посещений реальных пользователей-участников. Эти результаты зависят, в частности, от используемых ими устройств и сетей. Они доступны не для всех страниц и дают ответ на иной вопрос, чем лабораторные испытания, проводимые в контролируемых условиях.

Для каждого показателя укажите, получен ли он в лабораторных условиях или в реальных условиях. Например, простой HTTP-запрос может фиксировать статус и время ответа, но не обеспечивает автоматического рендеринга и взаимодействия браузера. Поэтому на его основе невозможно оценить показатели LCP, CLS и INP как показатели пользовательского опыта в браузере.

Как правильно различать уровни кэша

A Кэш страниц может хранить готовый HTML-код для повторных запросов. Объектный кэш, в свою очередь, сохраняет данные приложения, необходимые WordPress для обработки. Кроме того, браузер может повторно использовать уже загруженные ресурсы локально; CDN может кэшировать контент на дополнительном уровне за пределами исходного сервера.

При «разогретом» кэше страниц вы повторно загружаете общедоступную страницу после документально зафиксированного периода «разогрева». Это актуально для часто посещаемого контента, но мало что говорит о том, насколько затратно его динамическое создание. Запишите, какой URL был «разогрет», а также какие правила кэширования и настройки CDN применялись.

Для запроса без кэширования необходимо указать Обход кэша проверяй его тщательно, а не просто принимай на веру. Зарегистрированная сессия может работать по другим правилам и предоставлять персонализированный контент. Проверяй фактический ответ: быстрый запрос мало что стоит, если он возвращает неверный или устаревший контент.

Первый визит в новом состоянии браузера не означает, что кэш сервера или CDN «холодный». Точно так же сбой CDN не означает автоматически, что кэш приложения очищен. Заголовки кэша могут давать подсказки, но, в зависимости от поставщика, не всегда подтверждают состояние каждого задействованного уровня; поэтому следует также документировать доступные настройки и методы проверки.

Без соответствующего расширения, обеспечивающего постоянное хранение данных, кэш объектов WordPress, как правило, ограничен конкретным запросом. Константа WP_CACHE Само по себе это не активирует ни Redis, ни какое-либо автоматическое решение для кэширования. Какую роль Redis и Memcached могут играть в качестве постоянного объектного кэша, объясняется в статье по теме Redis и Memcached на хостинге WordPress.

Подготовка к сравнению и утверждению

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

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

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

• Тариф, ограничения по ресурсам, местоположение сервера и версии программного обеспечения обеих сред.
• Тестовые URL-адреса и типы страниц, статус авторизации, файлы cookie, а также используемые тестовые учетные записи.
• CDN, кэш страниц и кэш объектов, включая правила, фазу прогрева и запланированный обход.
• Место проведения измерений, версия инструмента, профиль браузера и устройства, сетевые условия, время проведения и количество повторений.
• Профиль нагрузки, круг обязанностей, согласованный временной интервал для тестирования и конкретные пороги прекращения.

Для проведения нагрузочных тестов необходимо согласовать Выпуск Свяжись со всеми ответственными лицами и, при необходимости, с хостинг-провайдером, прежде чем создавать нагрузку. Уточни контактные лица, ограничения по ресурсам и порядок действий в случае сбоев. Исключи использование сторонних сервисов без их согласия; в частности, предотврати проведение реальных платежей, оформление заказов и отправку уведомлений. Заранее проверьте, действительно ли тестовая копия предотвращает такие операции.

Концепция измерения для типичных страниц

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

Для публичной статьи в блоге необходимо несколько раз измерить один и тот же репрезентативный URL, используя фиксированный профиль браузера и сети. Отметь, включены ли CDN и кэш страниц, а также как страница была «разогрета» перед тестами. Таким образом можно оценить скорость загрузки именно этой публичной страницы, а не автоматически — скорость загрузки страницы в сеансе с авторизацией.

Динамический поиск или просмотр учетной записи получает собственную серию тестов с предоставленными тестовыми данными и, при необходимости, тестовой учетной записью. Проверяйте не только код статуса: ответ должен соответствовать поисковому запросу или авторизованной учетной записи и быть актуальным. Кроме того, проверьте, запланирован ли Обход кэша действительно работает; одного файла cookie для этого недостаточно.

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

Постепенное наращивание нагрузки при тестировании

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

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

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

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

Запишите как заданную, так и фактически достигнутую скорость. Число итераций в секунду соответствует числу запросов в секунду только в том случае, если каждая итерация генерирует ровно один запрос. Кроме того, фиксируйте распределение времени отклика, ошибки и таймауты, а также проверку правильности содержимого: высокая пропускная способность с ошибочными ответами не является успешным подтверждением устойчивости к нагрузке.

Проводить прозрачный анализ рядов измерений

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

Der Медиана описывает среднее значение отсортированных успешных измерений. 95-й процентиль, сокращённо p95, дополнительно указывает пороговое значение, ниже которого находятся примерно 95 процентов этих измеренных значений. При небольшом количестве запросов p95 сильно зависит от отдельных наблюдений; поэтому всегда указывайте размер выборки и с осторожностью интерпретируйте различия.

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

Сохраните исходные данные, тестовый скрипт и настройки вместе с протоколом. Так позже можно будет проверить, какие запросы были включены в анализ и можно ли вообще сравнивать две серии результатов. Не выбирайте задним числом только самый быстрый прогон: если результаты сильно пересекаются, наблюдаемое различие может находиться в пределах колебаний.

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

Определить причины и провести повторное измерение

Начните поиск неисправности с полученного ответа: совпадают ли содержание, статус авторизации и тестируемый URL? Затем проверьте задокументированный Состояние кэша и условия тестирования. Различные файлы cookie, другое место проведения тестирования или изменение правила CDN могут привести к различиям в результатах двух запусков, даже если производительность самого стека приложения не изменилась.

Только после этого имеющиеся эксплуатационные данные помогут сузить круг поиска: загрузка ресурсов и очереди могут указывать на узкие места, а информация о приложениях или базах данных — на ресурсоемкую обработку. Один-единственный низкий показатель HTTP не указывает на причину. WordPress называет в качестве факторов, влияющих на производительность, помимо хостинга, также программное обеспечение, настройки и контент.

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

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

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

Правильно оценить результат хостинга

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

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

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

Укажите результат вместе с тарифом, состоянием веб-сайта, протестированными URL-адресами, правилами кэширования и CDN, местом проведения измерений, а также периодом времени. Кроме того, уточните, сравнивали ли вы максимально сопоставимые стеки или предлагаемые в каждом случае комплексные пакеты. При сравнении пакетов различия в конфигурации могут повлиять на результат; такое сравнение не позволяет автоматически выделить чистое производительность сервера.

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

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