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

Question

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

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

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

Answer 1

Вот различные советы/предложения:

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

• Если ваше приложение является существующим приложением, которое уже развернуто на производстве, то то, что вы должны делать, - это тестирование производительности.

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

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

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

Answer 2

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

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