Сервер разработки / производственный сервер для стресс-тестирования

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

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

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


stress-testing
person ChrisInCambo    schedule 17.03.2009    source источник

Ответы (2)


arrow_upward
6
arrow_downward

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

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

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

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

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

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

person jwanagel    schedule 17.03.2009

arrow_upward
2
arrow_downward

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

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

person RnR    schedule 17.03.2009