Назад | Перейти на главную страницу

Что лучше: стресс-тест всей системы против профилирования и стресс-тестирования отдельных частей?

Я работаю в компании, которая полностью работает в облаке, и мы начали проект стресс-тестирования. Идея состоит в том, чтобы загрузить все производственные процессы в новую среду и запустить стресс-тесты для определения общей емкости системы и определения узких мест.

Теперь я вспоминаю время, когда мы проводили стресс-тесты физических серверов, а также частных облаков, и я помню, что было почти невозможно получить полную копию производственной среды и всех ее движущихся частей. Кроме того, даже с такими инструментами стресс-тестирования, как sysbench, Jmeter и ab, вы никогда не сможете точно смоделировать трафик, как производство.

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

Для расчета емкости мы использовали (а некоторые до сих пор используют) расчет, чтобы предсказать, когда емкость будет достигнута, или если время отклика будет ниже удовлетворительного уровня.

Учитывая, что проект по воссозданию производственной среды и стресс-тестирования требует значительных затрат времени и ресурсов, это лучший способ найти узкие места в системе и измерить пропускную способность или «старый» способ лучше?

Всегда лучше нагружать всю систему и использовать производственную среду (или даже производственную среду).

Прежде всего проверьте Может ли пропорционально уменьшенная среда тестирования обнаружить проблемы с производительностью? вопрос и ответы на него.

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

Так что по возможности всегда отправляйтесь на тестирование системы в реальных условиях. Если это невозможно, вы все равно можете запускать нагрузочные тесты, тестирование в уменьшенной среде, однако не ожидайте, что вы сможете точно экстраполировать результаты, например, эта машина имеет 10 ГБ ОЗУ и способна выдержать 1000 запросов в секунду, эта машина имеет 20 ГБ оперативной памяти, поэтому это будет 2000 запросов в секунду - так это не сработает. .