Стресс-тестирование сервера разработки / производственного сервера

Question

Я новичок в стресс-тестировании и просто пытаюсь научиться веревкам. Итак, мои вопросы:

1. Если у меня есть сервер разработки, который с точки зрения программного обеспечения идентичен, но с точки зрения аппаратного обеспечения имеет гораздо более низкие характеристики, чем рабочий сервер, стоит ли проводить стресс-тестирование сервера разработки для выявления явных дефектов программного обеспечения? *

2. Как лучше провести стресс-тестирование живого рабочего сервера, не подвергая опасности опыт ваших пользователей? Или следует избегать стресс-тестирования живого производственного сервера.

Answer 1

Вот несколько советов / предложений:

• Если ваше приложение новое, и вы не знаете, сможет ли оно справиться с нагрузкой, с которой оно будет работать, то вам необходимо провести тестирование «емкости». Вам следует провести тестирование емкости на производственном оборудовании, которое, поскольку оно еще не запущено, не повлияет на пользователей.

• Если ваше приложение является уже существующим приложением, которое уже развернуто в рабочей среде, то вам следует провести тестирование «регрессии производительности».

• Регрессивный тест производительности состоит из проведения стресс-теста всех отдельных «функций» (что бы это ни значило для вашего приложения) на вашем сервере разработки для измерения его производительности. Вы ведете учет результатов в качестве «базового уровня».

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

• Если результаты регрессии производительности на вашем сервере разработки не сильно изменились по сравнению с базовой линией, то вы должны быть в безопасности для развертывания в производство без изменения использования вашего сервера (т. Е. Перегрузки).

Answer 2

Я думаю, что вам следует избегать любой работы, включая стресс-тестирование на производственных машинах, если только вы не знаете, что у вас есть проблема, которую вы не можете воспроизвести в своей тестовой среде - при этом возможно, вы знаете , что ваши пользователи не использовать систему ночью? Если тесты не навязчивые / только для чтения, я бы сказал, что это дополнительная опция.

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