Что такое хороший стандартный показатель стабильности в веб-приложении?

Question

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

Мы хотели бы написать очень простое измерение для нашего партнера-подрядчика. Мы подумали о нескольких идеях:

• Система, которая способна выявлять большие объемы запросов и обслуживать недоступные серверы, попробуйте снова страницы, пока не восстановится после высокой нагрузки.
• Количество одновременных пользователей или просмотров страниц, которые позволят нам иметь четкую метрику того, когда использовать такие параметры масштабируемости, как Load Balancer и Caching.

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

Спасибо за вашу помощь.

Answer 1

«Высокая нагрузка» действительно трудно определить.

Нам намного проще определить минимально приемлемые уровни обслуживания.

1. Минимальное количество одновременных запросов.

2. Максимальное время для обработки запроса.

3. Минимальное количество запросов в час.

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

Обратите внимание, что при этом «минимумы становятся максимумами». Если вы скажете, что они должны обслуживать не менее 10 000 запросов в час, то при тестировании часто будет показано, что это тоже максимум.

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

Answer 2

Вам понадобятся следующие параметры:

1. Испытание под нагрузкой:

   i) Оцените поведение вашего приложения .. (т.е.) нет. ожидаемых одновременных пользователей, типичная активность пользователя

   ii) Загрузка приложения постепенно и просмотр параметров, таких как загрузка процессора, время отклика, пропускная способность и т. Д.

2. Устойчивость:

   Загрузите приложение (при оптимальной загрузке) в течение значительного времени (12-24 часа) и посмотрите на те же параметры использования процессора, уровни ошибок и т. Д.

Вы также можете попробовать масштабируемость, при которой вы добавляете оборудование постепенно и отслеживаете поведение приложения.

Это должно дать вам приличное понимание поведения вашей системы.

Answer 3

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

Эти вещи могут быть легко протестированы и проверены с помощью чего-то вроде LoadRunner, или вы можете запустить свой собственный аналогичный тестер нагрузки, используя что-то вроде HttpUnit.