Как часто приложения должны подвергаться нагрузкам или нагрузкам?

Question

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

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

Answer 1

Это действительно зависит от того, как вы хотите решить эту проблему для нужд вашей компании. Лично мы ежедневно тестируем наши интеграционные (тестовые) сборки - так же, как сборки выходят. После того, как сборка запускается со скоростью около 1а, у нас также есть сценарий для тестирования под нагрузкой. Нашей целью является именно поиск изменений в производительности. Даже если мы не вносим изменения в код, серверы, на которых тестируется код, по-прежнему получают обновления / исправления / исправления / пакеты обновления / и т. Д. В худшем случае после автоматизации он предоставляет дополнительные исторические данные.

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

Судя по всему, вы тестируете лабораторию, которая копирует производство? Это другой подход, чем у нас, потому что мы предполагаем, что большинство наших узких мест будет вызвано кодом и не будет напрямую зависеть от аппаратного обеспечения. Мы используем виртуальные машины, чтобы приблизить, но не дублировать нашу производственную среду.

Answer 2

Одна вещь, которая влияет на производительность системы, даже если код остается неизменным, это данные.

Примером может служить производительность запроса к базе данных. По мере добавления данных в таблицу стоимость обслуживания индексов возрастает. Разделение страниц в индексе может снизить производительность. По мере роста индексов количество «уровней» в индексе будет все чаще приходиться увеличивать. Когда это происходит, вы видите внезапное, по-видимому необъяснимое изменение в производительности.

Проведение стресс-тестов в производственной среде не всегда возможно - это влияет на ваш повседневный бизнес. Чаще всего системы снабжены инструментами для обеспечения постоянной обратной связи о производительности. Может быть, использовать что-то вроде ganglia . Данные используются для выявления проблем и планирования мощности.

Answer 3

Мои два цента: иногда вы ничего не измените, и производительность вашего сайта может пострадать. Это может быть из-за того, что приложение обрабатывает слишком много данных (например, переполнение кэшей). Это может быть от сторонней рекламы на сайте, замедляющейся. Черт, это может быть из-за ошибки RAM!

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

Моя компания, BrowserMob, предоставляет бесплатную услугу мониторинга сайта , которая запускает настоящие сценарии Selenium каждые X минут для вашего сайта. Хотя это не нагрузочный тест, он определенно может помочь вам определить тенденции и узкие места на вашем производственном участке.

Answer 4

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

Answer 5

Если ваше программное обеспечение может кого-то убить, думаю, вам следует.

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

"Timeout.exception: ваше сердце больше не приходит. Попробуйте позже"

Answer 6

Я думаю, что мы не хотим стресс-тест Блокнот. Это шутка. Не бери в голову =).

Стресс-тестирование не для всех приложений. : -)

Answer 7

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

Я думаю, как часто это будет зависеть от вашей среды.

Если вы не можете по-настоящему подвергнуть стресс-тестированию в процессе разработки, вам, возможно, придется подождать, пока вы не доберетесь до QA, где вы тестируете, непосредственно перед тем, как приступить к работе.

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

Я использовал junitperf для многих моих стресс-тестов.

Answer 8

Если в ваш продукт не внесены изменения и нагрузочное тестирование просто повторяет один и тот же процесс снова и снова в течение некоторого интервала, я не вижу преимущества повторного запуска.

Answer 9

Зависит от того, сколько усилий требуется для тестирования. Если это достаточно просто, больше испытаний никогда не повредит. Тем не менее, я не вижу причин для проверки, если не ожидается никаких изменений. Если это приведет к тому, что программное обеспечение не будет тестироваться в течение длительного времени, тогда может быть целесообразным время от времени запускать тесты в случае неожиданных изменений. Само собой разумеется, это также зависит от того, работает ли на вашем программном обеспечении ядерный реактор или доска объявлений.

Answer 10

Это зависит от того, насколько критически важна ваша система ... если это всего лишь небольшой инструмент, без которого можно обойтись, как только вы запустите его в производство. Если от этого зависит ваша жизнь, то после каждой сборки.

Насколько я понимаю, это так.