12 февраля 2022 в 16:56
Идея
Возникла необходимость по быстрому прикинуть скорость работы сервера с Drupal7 по SSH не устраивая каких-то сложных бенчмарков типа JMeter.
Идея: просто по циклу загрузить с сотню раз ядро Drupal и посмотреть сколько оно времени у сервера заняло.
Подготовка
Для этого создадим простой скрипт bench.php, в котором вам надо изменить $path до директории с Drupal:
<?php
$path = '/var/www/drupal7';
$_SERVER['REMOTE_ADDR'] = "127.0.0.1";
$_SERVER['SCRIPT_NAME'] = 'index.php';
$_SERVER['SCRIPT_FILENAME'] = 'index.php';
$_SERVER['REQUEST_METHOD'] = 'GET';
error_reporting(E_NOTICE);
chdir($path);
define('DRUPAL_ROOT', getcwd());
require_once DRUPAL_ROOT . '/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
include_once $path.'/includes/bootstrap.inc';
drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
?>При желании в него можно добавить загрузку ноды:
<?php
$node = node_load('1234');
?>А если хочется проверить запись, загруженную ноду сохранить:
<?php
$node = node_load('1234');
node_save($node);
?>Измерения
У нас есть скрипт, остается его выполнить с сотню раз из bash-а и замерить время:
В итоге получим что-то типа:
user 0m15,811s
sys 0m3,498s
Таким образом можно сделать выводы о производительности сервера.
Здесь real - общая продолжительность 100 загрузок, user - затраченное процессорное время в пространстве пользователя, sys - в пространстве ядра ОС (смотри man time).
Ограничения подхода
Так как запуск идет из командной строки сервера, скорее всего opcache использоваться не будет (настраивается).
Тест однопоточный. Многопоточную производительность он не проверяет.
По сути движок темизации не задействуется и вообще не участвующие в bootstrap модули не задействуются.
Нельзя сравнивать системы с разным числом активных модулей.
В целом метод позволяет быстро и грубо прикинуть производительность серверного железа. Я на своей цифровой библиотеке измерил скорость и вроде более менее соответствует:
LXC, Xeon E5-2690, SSD Samsung 840 PRO, ELiS, php 7.2, PostgreSQL12, CentOS 8
real 0m19,501s
user 0m15,853s
sys 0m3,473s
Hyper-V, Ryzen 7 PRO 5750GE, SSD SK hynix PC711, ELiS, php 7.3, PostgreSQL12, Oracle Linux 8
real 1m25,231s
user 0m17,910s
sys 0m1,780s
VMware ESXi 5.1, Xeon X5670, IBM XIV, ELiS, php 7.2, PostgreSQL12, CentOS 8
real 0m35.606s
user 0m23.898s
sys 0m7.668s
VMware ESXi 5.1, Xeon L7555, IBM XIV, ELiS, php 7.3, PostgreSQL12, CentOS 8
real 1m24.610s
user 1m9.237s
sys 0m8.076s
Написанное тестировалось на Drupal7, но думаю на более старших можно быстро накидать аналогичный тест.
Комментарии
По сути говоря, сто раз запускается одна и та же программа. Тогда есть вариант короче:
time for ((i=0; i<100; i++)); do ls /etc; doneЕсли серьезней, то данный вопрос всегда актуальный. Для примера
Способ быстрого измерения производительности случайного сервера
Как правильно мерять производительность диска
Как оценить производительность Linux-сервера: открытые инструменты для бенчмаркинга
Само-собой, оверселлинг, и, как следствие, сбор статистики.
В варианте ls /etc вы измеряете производительность переключения контекста и скорость листинга файлов в файловой системе, согласитесь, совсем не тоже самое, что инициализировать ядро Drupal -)
Теперь по универсальным бенчмаркам.
Вот вы измерили fio скорость дисков. Увидели, что на 4k рандомом такая производительность, на 1M последовательно сякая. Дальше что? Вам же сервер нужен не для бенчмарков, а чтобы Drupal на нем гонять. Значит надо как-то эти цифры к Drupal подбить.
Но как те цифры, которые вы видите в универсальных бенчмарках, стыкуются с производительностью Drupal, вы можете оценить? Думаю, что нет. А нет, потому-что если ОЗУ достаточно, то чтение из RAM идет и если у вас записи мало в базу (что бывает часто, что в базу Drupal вы пишите раз в сутки, а остальное время читаете), то производительность дисков может вообще мало на что влиять.
Тоже самое и про производительность других бенчмарков. К примеру бенчмарк pgbench насилует сервер базы данных записью (записи сильно больше чтения). Это ваша типичная нагрузка на сервер с Drupal+PostgreSQL? Думаю нет. Что вы такой нагрузкой измеряете? Что-то измеряете, но оно совсем далеко от того, чем у вас Drupal занят на самом деле в типичном профиле работы.
И особо отмечу, что мне интересна не производительность сервера вообще по fio или CPU, да, согласен, есть универсальные бенчмарки вот по ссылкам, мне интересна какая-то цифра, которая говорит о производительности связки php+БД под Drupal на разных серверах. Т.е. "на этом сервере Drupal будет работать в 2 раза быстрее, чем на том".
Здесь рядом еще вариант с ab привели. Тоже способ, в чем-то имеющий преимущества, в чем-то недостатки.
С оверселингом да, будут сильные колебания результатов, будет зависимость от времени суток и т.д. Вообще это просто понять, что данные недостоверные: результаты не повторяются при повторных запусках. Я на этом бенче это проверял, повторяемость есть.
Не могу понять, скорость чего именно вы измеряете?
За какое время 100 раз выполнится программа на разном железе ))
Получается больше ничего. К определению производительности (пригодности для эксплуатации) имеет очень отдаленное отношение, так как приводит к ошибочным выводам, слишком упрощено. В статьях и комментариях из ссылок вопрос шире раскрыт.
С производительностью веб приложений всё концептуально намного сложнее.
Даже если подходить максимально просто, есть по меньшей мере две метрики:
- Время исполнения отдельного запроса, которое тут измеряется.
- Количество запросов в единицу времени, которое может обработать сервер.
Так вот, какой сервер быстрее - тот который может обработать больше запросов в единицу времени, или тот, что обработает один запрос быстрее?
В общем, это слишком большое упрощение, чтобы данные такого теста, были бы хоть сколько-то ценны.
Второй момент: способ тут описанный имеет концептуальный изъян даже для оценки скорости выполнения отдельного запроса. Изменять время бутстрапа довольно бесполезно. Оно может плохо коррелировать с производительностью. И больше будет сказываться, например, тип кеша для бустрапа, который обычно занимает относительно малое время, по сравнению со временем среднего запроса. Если уж делать тесты подобные, надо выбрать более сложный сценарий для оценки, ну и куда сложнее даже загрузки ноды, или её сохранения. Ну и надо измерения производить в реальном окружении, потому, что могут быть очень разные ограничения для cli и web.
Самый простой тест, который хоть что-то оценит, это несколько запусков ab с разным количеством потоков, относительно какой-то страницы одинакового сайта, и дальнейшая аналитика результатов.
Тут и rps, и скорость отдельных запросов, и отклонения можно посмотреть. И составить хоть сколько-то реальную картину и уже что-то сравнить.
Все верно, это про одноядерную производительность, так и написал в ограничениях -)
Я проводил тесты и с масштабируемостью по процессорам все очень просто: пока ресурсов хватает (процессор в полку не забит), она линейная. Т.е. если знаете сколько запросов может одно ядро обрабатывать, умножаете на количество ядер и получаете многоядерную производительность.
ab тоже неплохой вариант по быстрому проверить, но ab не умеет сохранение проверять, только чтение.
Вообще имеет смысл сравнить предложенный метод с ab. Apache Benchmark измеряет время генерации страницы, а не bootstrap, вот и вся разница если у вас ab -c 1. Минус ab как средства измерения производительности: оно долбит все в закешированную страницу и, соответственно, вы видите закешированные данные. Кроме того, оно долбит все время в одну и туже страницу и если у вас есть страница node/1 легкая с 50 мс., а node/2 тяжелая со временем 100 мс, то чему верить? Т.е. у вас больше параметров искажает результаты (еще более сильная зависимость от включенных модулей), чем измерять только bootstrap.
Теперь вернемся к предложенному мной тесту, его можно адаптировать, например добавляете:
<?php$node = node_load($random_nid);
node_view($node);
?>
и вот вы уже загрузку и рендеринг нод измеряете -)
Для ab тоже можно что-то такое сделать: написать страницу с нужным вам кодом и долбиться в нее. Так когда-то и делал в виде модуля с неким URL по которому выдается случайная нода (чтобы убрать влияние кеширования ab одной ноды).
В итоге и приведенный мной метод и ab можно использовать, зависит от тех задач, которые вы решаете и на что посмотреть хотите. Если надо время генерации страницы, так нет причин не использовать ab.
Если же вам надо спрогнозировать какую нагрузку выдержит ваш конкретный сайт на конкретном железе, так ни предложенный мной способ не подходит ни ab. Надо заморачиваться с JMeter.
Этот метод подходит для сравнения, а не как какой-то синтетически бенчмарк выдающий какую то цификру "производительность", которая обычно бесполезна чуть более чем полностью...
И в зависимости от того, что мы хотим сравнить надо выбирать нужную страницу, и отключать кеширование, если надо сравнивать полноценно генерацию страниц.
Ну и конечно не -c 1 - это не имеет смысла почти никогда. Кроме процессора есть ещё настройки - количество обработчиков, например. Есть хранилище где может быть ограничение iops.
Надо изменять с достаточной параллельностью, и заодно выяснять пределы, последовательно её увеличивая.
Для сравнения. Да.
Соглашусь, заголовок поста в этом смысле не очень удачен. Но с другой стороны все эти попугаи в каких-нибудь GeekBench или tps в pgbench или даже iops в fio разве тоже не для сравнения?
Вообще ab имеет смысл и с -с 1:
1. Это показатель скорости ответа вашего сайта, который влияет на SEO, так что если у вас большая доля трафика из поиска за него имеет смысл рубиться.
2. Положим у вас такая нагрузка на сайт, что на нем открывают в среднем 10 страниц одновременно (ab -c 10). Время генерации страницы 1 сек. Значит за одну минуту на вашем сайте откроют 600 страниц. За час 2 160 000 страниц.
2 160 000 открытых страниц - это сколько человек? Ну если за посещение один уник открывает в среднем 2 страницы, это 1 млн. посетителей в час. С учетом суточных пиков и т.д., за сутки это ну положим не 24 часа * 1 млн., а 10 * 1 млн. = 10 млн. уников в сутки.
У многих такие сайты на Drupal c 10 млн. уников в сутки, чтобы с ab -c 10 тестировать?
1. Это не совсем так. В реальном использовании так не будет. Точнее так будет только тогда, когда ресурсов выделено существенно больше чем надо или только в то время, когда посещаемость будет очень низкой. И на ceo будет влиять не эта идеальная величина, а скорость ответа средняя под параллельной нагрузкой, именно и за неё и нужно бороться.
2. Почти никогда линейно это всё не меняется. А посещаемость не размазана ровно по суткам. Почти всегда есть очень большие пики. Она даже в рамках минут может очень сильно меняться. Так что такие прикидки надо делить на порядок, а иногда и не на один, чтобы сайт мог пережить пики. В общем, эта прикидка уж очень не реальна.
Ну я и учел, что не размазана ровно по суткам и умножил не на 24 часа, а на 10 -)
Касательно пиков: тогда лучше на примерах. Вот на drupal.ru по similarweb в январе было 90k визитов. Сколько в секунду пиковая нагрузка максимальная была и как это измерялось?
На drupal.ru, который тут кстати плохой пример, т.к. охват аудитории довольно широк, также на него не редко заходят и в рабочее время, и зависимость посещаемости от времени одна из наиболее ровных, из тех сайтов, по которым у меня есть информация, следующие данные по соотношению минимума/максимума запросов:
RPH (запросы по часам): 1/1.74
RPM (по минутам): 1/6.6
RPS (по секундам): 1/24 на самом деле от 0 до 24.
Данные напрямую из логов за вчера.
Становится понятнее, почему именно не правильна прикидка с 10 условными часами даже тут? Не говоря о каком-нибудь сайте имеющем куда более выраженную разницу в посещаемости во времени, а таких большинство.
Статистика не такая простая штука, как кажется на первый взгляд, и с ней надо быть по аккуратнее...
Никто не спорит, есть вероятность, что 24 человека в одну секунду решат сайт открыть и он у них будет открываться в разы медленнее, но это маловероятное событие. Если таких "медленных" запросов будет меньше 1%, то ими скорее можно пренебречь. Медианное же значение в те секунды, когда нагрузка есть, скорее всего в районе 1-2 RPS.
Здесь еще вопрос, не попала ли статика в эти "до 24 RPS", если попала, то 24 можно поделить в 3-6 раз за счет статики, которая ядро Drupal не дергает.
Конечно, у кого-то могут быть сайты на обычных CMS с достаточно большой нагрузкой, но большинство же, увы, имеют небольшую.
Ну и конечно, у кого большая нагрузка, тому надо многопоточные бенчмарки.
Это какой-то сферический конь в вакууме. Если взять главную страницу какого-нибудь реального сайта, то там скорость загрузки и рендеринга ноды будет составлять ничтожно малое количество времени из общего времени генерации страницы. Если делать тесты, то нужно рендерить страницы целиком и никак иначе. Не ноды, не какие-то другие сущности, а именно страницы. Чем отличается страница от сущности? Тем что на странице куча блоков, вьюсов, меню, форм и прочего барахла.
Все верно.
Если вам нужно производительность сайта (а не сервера под запуск сферического Drupal в вакууме), причем конкретного сайта со 100500 развернутыми модулями, блоками и т.д. - JMeter и вперед. Инфы по JMeter достаточно.
Смешались в кучу пони, люди, попугаи...
Разве трудно было написать в начале статьи: "Я запускал свой скрипт/программу/бенч на таких-то гипервизорах с такими-то системами хранения данных. Получил такие-то результаты. Они прямо коррелируют с результатами JMeter. Отсюда -> вывод..."
Сразу было бы понятно, что здесь подразумевается под серверами и производительностью. Не все люди ходят по ссылкам. А так очередной Фома-Ерема получился.