Архивный материал. Описанные методики или устарели или не используются.
Предварительные результаты эксперимента по построению эпюры производительности СУБД PostgreSQL по итогам стресс-тестирования
Сценарий стресс тестирования
Последовательное увеличение нагрузки в виде количества подключений (параметр clients утилиты pgbench)
Периодичность тестовой нагрузки = 15 минут
Начальное значение нагрузки = 20
Приращение нагрузки на каждом шаге стресс тестирования = 10
Сглаживание значений и исключение выбросов
Медианное сглаживание с периодом 1 час.
Слабая тестовая ВМ ( 1 CPU )
Максимальная нагрузка = 40 соединений . Далее катастрофическая деградация производительности и предельная утилизация ресурсов ВМ.
Нагрузка
Время отклика
Аппроксимированный график производительности
Вывод
Для столь маломощной ВМ необходимо существенно снизить нагрузку и уменьшить приращение .
Хотя даже по столь малым данным можно предположить, что линейное увеличение нагрузки на СУБД влечет за собой нелинейное снижение производительности
Мощная тестовая ВМ (24 CPU )
Стартовая нагрузка = 30
Максимальная нагрузка = 260
Тест остановлен по времени и увеличению времени отклика более чем в 20 раз.
Нагрузка
Время отклика
Производительность СУБД
Выводы
1. Изменение времени отклика практически прямо пропорционально нагрузке на СУБД .
2.Скорее всего, при продолжении нагрузки на СУБД график времени отклика будет стремится к горизонтальной асимптоте.
3. Ожидаемо, производительность СУБД обратно пропорциональна нагрузке на СУБД и близка к графику функции K/X.
4. Диапазон штатной работы СУБД ( постоянное время отклика ) до 60 тестовых соединений. Производительность до 2 150 836.
5. Критичная точка деградации производительности СУБД( резкий рост времени отклика ) после 120 тестовых соединений. Производительность менее 474 135.