"pgbench не бенчмарк" ?⁠⁠

Взято из архива основного технического канала Postgres DBA

Предисловие

В ходе работ по подготовке эпюры производительности СУБД в очередной раз была получена иллюстрация проблем использования среднего арифметического при расчете производительности СУБД .

Последовательный рост нагрузки на СУБД

Результаты pgbench

Первые же результаты , показали несогласованность pgbench - TPS - с реальными показателями производительности СУБД

Значение tps получено тривиально, из результата теста :

лог | grep tps

Среднее время отклика СУБД

Время отклика вычисляется , также, стандартно:

SUM(total_exec_time) / SUM(calls)

За период из представления pg_stat_statements.

И тут возникает 2 варианта анализа результатов:

1) Если ориентироваться на результаты pgbench, то , при росте количества подключений c 60 до 70 - tps вырос с 12870,870996 до 13294,489494 (+3%)

2) Если ориентироваться на среднее время отклика СУБД , то, при аналогичном росте количества подключений c 60 до 70 - среднее время отклика увеличилось на 100%

Вопрос - как анализировать результаты теста ?

Производительность СУБД растет с ростом нагрузки или нет ?

P.S.

Очередная иллюстрация на тему - ни TPS , ни время отклика - по отдельности не являются метриками производительности СУБД, потому, что не позволяют предсказать и описать реальную картину и получить объективные данные о реальной производительности СУБД .

P.P.S. Также нужно отметить, что история и анализ данных tps из лога pgbench с помощью grep - не самая удобная процедура . Особенно если не одна итерация, а несколько десятков.

Так, что - как средство создания нагрузки pgbench вполне рабочий и удобный инструмент. Как средство анализа результатов - нет.

Послесловие

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

В связи с проблемами более подробно разобранными в статье О проблеме использования mean_exec_time при анализе производительности PostgreSQL