Бенчмарк на PHP

[kudashevs]

Всем привет,

Не так давно появилась необходимость пробежаться по хостингам и сделать какие-то простейшие замеры, как на них работает PHP (не углубляясь в детали, просто общую картину). Под эти нужды был найден простой скрипт php-benchmark-script.com, написанный очень давно, ну и разные его форки. Возможности тестирования и их функционал оказались для меня весьма ограниченными.

Собравшись с мыслями, решил написать свой бенчмаркер, т.к. иногда хочется получить хотя бы какое-то представление о том, что происходит на хостинге/VDS/VPS с PHP из самого PHP и сравнить его с другими вариантами. Бенчмаркер было решено сделать в виде CLI приложения, устанавливающегося через composer: https://packagist.org/packages/kudashevs/benchmark-php

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

Вообще цель поста это конструктивная критика. Просьба к участникам сообщества высказать свои пожелания, замечания, предложения. Просьба к более опытным товарищам покритиковать код, если есть возможность. Хотелось бы критики по декомпозиции, по организации кода, что можно упростить, где-то сделать лучше используя паттерны, возможно что-то сделано категорически неверно или что-то можно просто улучшить. При разработке следовал PSR-2, для анализа кода использовал phpstan. Проект на github: https://github.com/kudashevs/benchmark-php/tree/master

Всем заранее спасибо

 

[fixxxer]

А покажи, что намерил, и насколько намерянное позволяет делать выводы. Скажем, сравнение разных типов инстансов на aws.

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

 

[kudashevs]

К сожалению сравнения разных инстансов на AWS не покажу, у меня их нет. Приведу два примера и два способа применения, которые мне позволили принимать какие-то решения. Есть два хостинга (spaceweb – shared, hostinger – vps).

Пример первый: замер скорости работы с разными типами данных
Сначала коснусь spaceweb, там два аккаунта, соответственно два разных сервака, где они висят. Разница в цене в разы, назовем их продвинутый и простой (конкертно называть тарифы не буду, могу в личку скинуть). Делаем несколько прогонов: vendor/bin/benchmark-php -a -e filesystem

Продвинутый (дорогой)

--------------------------------
|     Benchmark PHP 2.1.0      |
--------------------------------
Server: vip***
Platform: Linux (x86_64)
PHP version: 7.0.33
Zend version: 3.0.0
Xdebug: not installed
--------------------------------
integers: 0.342s
floats: 0.374s
strings: 1.199s
arrays: 1.825s
objects: 0.259s
--------------------------------
Total time: 4.001s

Обычный (дешевый)

--------------------------------
|     Benchmark PHP 2.1.0      |
--------------------------------
Server: vh***
Platform: Linux (x86_64)
PHP version: 7.0.33
Zend version: 3.0.0
Xdebug: not installed
--------------------------------
integers: 0.322s
floats: 0.394s
strings: 0.998s
arrays: 1.573s
objects: 0.255s
--------------------------------
Total time: 3.544s

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

--------------------------------
|     Benchmark PHP 2.1.0      |
--------------------------------
Server: ***
Platform: Linux (x86_64)
PHP version: 7.2.26
Zend version: 3.2.0
Xdebug: not installed
--------------------------------
integers: 0.299s
floats: 0.397s
strings: 1.220s
arrays: 1.970s
objects: 0.344s
--------------------------------
Total time: 4.231s

Пример второй: замер скорости работы с файловой системой

Подробнее зачем мерить скорость работы с файловой системой будет в P.S. Начнем с дорого spaceweb, на нем заявлены SSD и все такое.
Продвинутый (дорогой)

--------------------------------
|     Benchmark PHP 2.1.0      |
--------------------------------
Server: vip***
Platform: Linux (x86_64)
PHP version: 7.0.33
Zend version: 3.0.0
Xdebug: not installed
--------------------------------
filesystem: 1.264s
read_time: 0.834s
read_speed: 1.006GB/s
write_time: 0.430s
write_speed: 1.949GB/s
--------------------------------
Total time: 1.264s

Сравниваем с дешевым аналогом без SSD и видим, что действительно скорость работы с файловой системы у нашего дорогого варианта явно выше.
Обычный (дешевый)

--------------------------------
|     Benchmark PHP 2.1.0      |
--------------------------------
Server: vh***
Platform: Linux (x86_64)
PHP version: 7.0.33
Zend version: 3.0.0
Xdebug: not installed
--------------------------------
filesystem: 1.726s
read_time: 1.148s
read_speed: 0.731GB/s
write_time: 0.578s
write_speed: 1.451GB/s
--------------------------------
Total time: 1.726s

Но что же vps от hostinger. А вот тут самое интересное, здесь нас ожидает провал. И оно как бы VPS, а как бы с ним есть некоторые проблемы, с которыми нам предстоит разобраться.

--------------------------------
|     Benchmark PHP 2.1.0      |
--------------------------------
Server: ***
Platform: Linux (x86_64)
PHP version: 7.2.26
Zend version: 3.2.0
Xdebug: not installed
--------------------------------
filesystem: 19.815s
read_time: 1.666s
read_speed: 0.503GB/s
write_time: 18.149s
write_speed: 0.046GB/s
--------------------------------
Total time: 19.815s

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


P.S. Изначально долго думал, вообще писать или не писать это приложение, однако статья меня натолкнула на мысль, что мерить командой dd это конечно круто, но только не совсем релевантно, потому что PHP это еще несколько уровней абстракции над этим всем и работать из него может все не так, как оно ожидается.

P.S.S. Не смогу сейчас привести уже пример, потому что отказался от одного из хостингов, но там прямо была просадка по объектам (можно гонять бенчмарки на определенные типы данных выбирая их опцией -b). Почему плохо работало с объектами, даже не стал разбираться, т.к. это был shared и просто поменял его и все.

@fixxxer такой вариант использования информативен/полезен?

 

[fixxxer]

Не очень понятно, как эти метрики применить. На php обычно задачи отличаются от подсчета чисел Фибоначчи или on-disk сортировки.

Вот есть у меня какой-нибудь, прости хоспади, вордпресс (или приложение на Laravel), на который в пике 5 хитов в секунду, как мне определить, какого тарифа мне будет достаточно?

Я могу, положим, установить этот самый вордпресс и погонять какой-нибудь http load tester по реальному (или хотя бы реалистичному) access log. Так будет понятно. А с этими цифрами что делать-то?

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

 

[kudashevs]

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

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

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

 

[grigori]

Тест бесполезен. В PHP и MySQL нагрузка разделяется по нескольким процессам.
В консольном тесте на числа 4 ядра с частотой 1 Ghz покажут в 2 раза меньше производительность, чем 1 ядро с частотой 2 Ghz.
Однако, общая способность обслуживать запросы 10-ю worker-ами php и базой mysql на 4 медленных ядрах будет в 2-3 раза выше, чем на одном быстром ядре.

 

[fixxxer]

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

Посравнивать всякие aws-ы с digital ocean-ами и linode-ами еще было бы интересно, но, опять же, надо учитывать количество воркеров.

 

[grigori]

Ситуация такая: на php работает 80% web/middleware в мире, которые пишет сотни тысяч разработчиков, и если такого несложного теста за 20 лет не появилось - значит, его сделать невозможно. Вспоминая о том, что php и mysql разносят на разные серверы, становится понятно почему - скорость сетевой инфрастуктуры в ДЦ важнее скорости процессора на отдельном сервере, потому что сеть между серверами часто тупит, и быстрые процы стоят ждут.

 

[kudashevs]

Тест бесполезен. В PHP и MySQL нагрузка разделяется по нескольким процессам.
В консольном тесте на числа 4 ядра с частотой 1 Ghz покажут в 2 раза меньше производительность, чем 1 ядро с частотой 2 Ghz.
Однако, общая способность обслуживать запросы 10-ю worker-ами php и базой mysql на 4 медленных ядрах будет в 2-3 раза выше, чем на одном быстром ядре.

Спасибо за развернутые комментарии. Да, многоядерность приложение никак не учитывает. Хотел бы уточнить такой момент, @grigori если переписать/расширить приложение реализацией pthread в вашем понимании это как то изменит ситуацию? То есть оно станет ближе к реальной картине с воркерами?

 

[kudashevs]

Конструктивная критика приложения говорит о его несостоятельности, т.к. оно не учитывает работы в несколько потоков, это теперь мне понятно. А возможна ли так же конструктивная критика кода?

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

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

 

[fixxxer]

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

 

[grigori]

Спасибо за развернутые комментарии. Да, многоядерность приложение никак не учитывает. Хотел бы уточнить такой момент, @grigori если переписать/расширить приложение реализацией pthread в вашем понимании это как то изменит ситуацию? То есть оно станет ближе к реальной картине с воркерами?

сформулируй цель - чего именно ты хочешь добиться?
Давай учитывать, что цена нормальной VPS - $5 в месяц, чашка кофе. Обычный сайт вроде этого форума на ней живет.
Чего мы можем добиться на основе теста? Сэкономить $1 - не нужно, я кофе не считаю.
@Adelf какой тариф у этого сайта?

 

[kudashevs]

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

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

Вопрос снимается, для себя в этом вопросе разобрался. Если кратко, то оверинжиниринг это "Code that solves problems you don't have.". Если кому-то будет интересно или интересно копнуть глубже, то более подробно написано в simplycode.

 

[kudashevs]

сформулируй цель - чего именно ты хочешь добиться?

Когда-то давно идея была быстро получать какую-то картину производительности хостинга (лет 7-8 назад), но это уже было реализовано и кто-то даже развивал. Потом появилась идея замерять скорость записи/чтения файлов из самого интерпретатора PHP (как писал выше > долго думал, вообще писать или не писать это приложение, однако статья меня натолкнула на мысль. Ведь если дяденька так заморачивается, возможно это еще кому-то надо.) В итоге решил объединить, улучшив идею, заодно лучше понять работу с файловой системой, ну и попрактиковаться заодно.

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

P.S. цель да, экономить копейки. В целом для меня это не критично, приложение писалось больше из интереса и возможности как-то улучшить свои навыки и уровень.

 

[grigori]

Хмм, поиграться - можно, но не расчетами php, а исполнением кода. Бери, например, простое приложение на Symfony, и тестируй компиляцию, загрузку, запрос к базе. Это больше работа с памятью, диском и настройкой opcache, чем вычисления.
Как это распараллелить - наверное, exec()/proc_open()
Только в тестах надо учесть preload в 7.4
Ты готов столько времени потратить?

 

[kudashevs]

Хмм, поиграться - можно, но не расчетами php, а исполнением кода. Бери, например, простое приложение на Symfony, и тестируй компиляцию, загрузку, запрос к базе. Это больше работа с памятью, диском и настройкой opcache, чем вычисления.
Как это распараллелить - наверное, exec()/proc_open()
Только в тестах надо учесть preload в 7.4
Ты готов столько времени потратить?

Не готов. За идею спасибо

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

 

[AmdY]

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