Сравнение производительности PostgreSQL: стандартный сценарий нагрузки.

Предыдущая методика оценки производительности - неактуально , в архиве.

Большому слону и еды надо больше

Архивный материал. Описанные методики или устарели или не используются.

Инженерия производительности (англ. Performance Engineering) — часть системной инженерии, включающая в себя набор ролей, знаний, практик, инструментов и результатов и применяющаяся на каждом этапе Цикла разработки программного обеспечения с целью убедиться в том, что создаваемое, программируемое и поддерживаемое архитектурное решение соответствует нефункциональным требованиям к производительности этого решения.

Важное уточнение

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

Задача эксперимента

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

Конфигурация ВМ

ВМ-1

Версия СУБД: Postgres Pro (enterprise certified) 15.8.1 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 11.4.1 20230605 (Red Soft 11.4.0-1), 64-bi

CPU: 8

RAM: 15

ОС: RED OS 7.3

ВМ-2

Версия СУБД: Postgres Pro (enterprise certified) 14.11.3 on x86_64-pc-linux-gnu, compiled by gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516, 64-bit

CPU: 24

RAM: 189

ОС: Astra Linux (Smolensk) 1.6

Тестовый сценарий и нагрузка на СУБД

Инструмент создания нагрузки: pgbench

Изменение нагрузки: экспоненциально начиная со значения --connect=6

Изменения в методике анализа результатов

1. Изменение методики расчета метрик производительности. Расчеты основаны на статистическом анализе данных представлений pgpro_stat_statements , pgpro_stat_total.

2. Из анализа исключена метрика "время отклика СУБД". Используется среднее время выполнения тестового запроса.

3. Из критерия остановки теста исключено условие роста времени выполнения запроса . Нагрузка растет одинаково на тестовые ВМ.

4. Из анализа производительности СУБД исключен критерий оценки по времени выполнения тестового запроса (режимы работы СУБД).

5. В качестве метрики производительности СУБД используется метрика - операционная скорость.

Результаты теста

Операционная скорость

График операционной скорости ВМ-1 . ВМ -2

Выводы

1. Характер графиков ВМ-1 и ВМ-2 существенно отличаются.
2. Операционная скорость ВМ-1 существенно выше чем показатели ВМ-2 до 230 соединений.
3. При превышении нагрузки свыше 276 соединений операционная скорость ВМ-2 выше и существенно не снижается с ростом нагрузки. Как и аналогичный показатель для ВМ-1.

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

ВМ-1 быстрее, при нагрузке до 63 соединений

Время выполнения тестового запроса при нагрузке до 63 соединений

ВМ-2 быстрее, при нагрузке свыше 64 соединений

Время выполнения тестового запроса при нагрузке свыше 64 соединений

Выводы

1. Время выполнения тестового запроса для ВМ-1 существенно растет с ростом нагрузки и превышает время выполнения тестового запроса для ВМ-2 при нагрузке свыше 64 соединения.

Итог

1. Если оценивать СУБД по времени выполнения тестового запроса , то до нагрузки 64 соединения - тестовый запрос на ВМ-1 выполняется быстрее.

2. Если оценивать СУБД по операционной скорости, то до нагрузки 230 соединений - операционная скорость ВМ-1 существенно выше.

3. В целом до нагрузки 230 соединений при выполнении тестового сценарий и тестовой нагрузке ВМ-1 эффективнее чем ВМ-2.

Продолжение