Бенчмаркинг процессоров серверов для PHP: тесты реальных рабочих нагрузок веб-хостинга

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

Бенчмарк PHP для процессора может, в первую очередь, показать, сколько времени требуется системе для выполнения заданной вычислительной задачи. Это особенно полезно, если отдельный запрос тратит много времени на вычисления в PHP. Более высокий Производительность одноядерного процессора может сократить время обработки такой задачи; однако на основании одного только показателя производительности процессора невозможно определить время отклика всего веб-сайта.

Второй вопрос касается поведения приложения при одновременных запросах: сколько правильных ответов оно выдает в секунду и сколько времени при этом приходится ждать пользователям? Для этого нужен Тест производительности веб-хостинга через HTTP. Он учитывает весь путь через веб-сервер и PHP, а также, при необходимости, базу данных, кэш и сеть. Именно это сочетание делает его применимым на практике, но не позволяет сделать однозначного вывода о нагрузке на ЦП.

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

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

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

Разграничение результатов тестов процессора и тестов приложений

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

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

SPEC CPU дополняет такие тесты стандартизированными рабочими нагрузками, требующими интенсивных вычислений. SPEC CPU 2026 содержит наборы тестов для целочисленных и плавающих точек, а также результаты по показателям «Speed» и «Rate». Показатель «Speed» отражает время выполнения задач, а «Rate» — пропускную способность. Значение «Speed» не всегда является чисто одноядерным показателем: в тестах на скорость вычислений с целыми числами набора 2026 SPEC указывает на наличие дополнительного параллелизма.

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

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

Определить сопоставимые условия испытаний

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

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

Особенно важно разграничить CLI и PHP-FPM: Тест в командной строке не всегда использует ту же конфигурацию среды выполнения, что и HTTP-запрос. Задокументируйте фактически используемые настройки OPcache и JIT для обоих контекстов. Их влияние и значения по умолчанию зависят, в частности, от версии PHP; для сравнения недостаточно использовать общие допущения.

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

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

Выбор подходящих рабочих нагрузок и показателей

Выбор теста зависит от того, на какой вопрос ты хочешь получить ответ. Один Микробенчмарк изучает ограниченную вычислительную задачу; HTTP-тест учитывает путь прохождения через веб-стек. Результаты SPEC дополняют сравнение стандартизированными системными тестами, интенсивно загружающими ЦП, но не заменяют тестирование собственного PHP-приложения.

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

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

Функцию приложения, требующую интенсивной работы процессора, можно дополнительно протестировать изолированно с помощью PHPBench — например, обработку данных без доступа к сети. Лучший результат на первых порах свидетельствует лишь о преимуществе данной функции в выбранных условиях выполнения. А вот даст ли это ощутимое преимущество для всей страницы, покажет тестирование приложения.

Провести тест Staging с помощью wrk

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

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

wrk -t2 -c4 -d30s --latency http://127.0.0.1:8080/

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

Однако стандартный вывод процентилей командой wrk не содержит значения p95. Для получения воспроизводимых результатов по p95 сохраните следующий скрипт на языке Lua на генераторе нагрузки как percentiles.lua. В статистике задержки приводятся значения p50 и p95 в микросекундах; если разделить их на 1 000, получится время в миллисекундах.

function done(summary, latency, requests)
  io.write(string.format("p50: %.0f us\n", latency:percentile(50.0)))
  io.write(string.format("p95: %.0f us\n", latency:percentile(95.0)))
end

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

wrk -t2 -c4 -d30s --latency -s percentiles.lua http://127.0.0.1:8080/

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

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

Фиксировать этапы нагрузки и результаты

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

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

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

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

Изучение FPM и ограничений ресурсов

Если при увеличении нагрузки растут как очередь, так и время отклика p95, стоит обратить внимание на пул PHP-FPM. Сравните текущие значения для active processes, idle processes и listen queue с настроенным верхним пределом pm.max_children. Если все разрешенные процессы активны, свободных процессов нет, а запросы находятся в очереди, это указывает на Граница бассейна или на работников с большим стажем, но не обязательно на слишком медленный процессор.

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

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

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

В случае VPS и виртуального хостинга выделенный vCPU не всегда соответствует отдельному физическому ядру. Если доступны данные cgroup-v2, то cpu.max настроенное ограничение пропускной способности ЦП; cpu.stat может, в частности, включать счетчики для Дросселирование содержатся. Изменение значений этих счетчиков во время выполнения помогает определить, действует ли ограничение.

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

Выявление разброса и погрешностей измерений

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

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

Микробенчмарк CLI также не является результатом FPM: он запускается в другом контексте выполнения и может использовать другие настройки OPcache или JIT. Задокументируйте фактически активные настройки обеих сред выполнения отдельно, а не выводите их из версии PHP. Преимущество, проявленное в микротесте, не обязательно проявится в HTTP-тесте приложения в той же степени.

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

Das Характеристики синхронизации также может способствовать рассеиванию. Выбор оптимальной настройки частоты зависит от платформы и нагрузки; универсальная настройка не заменяет сравнения в одинаковых условиях. Вклад в Регулятор частоты процессора на хостинг-серверах объясняет взаимосвязи для более углубленного анализа.

Использовать результаты при выборе хостинга

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

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

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

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

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