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

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

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

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

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

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


java web-applications tomcat stability
person Geo    schedule 28.04.2009    source источник

Ответы (3)


arrow_upward
5
arrow_downward

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

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

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

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

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

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

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

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

person S.Lott    schedule 28.04.2009
comment
Я бы добавил к этому одну вещь: убедитесь, что вы указываете требования к нагрузке с точки зрения типичных вариантов использования, которые, вероятно, увидит производственная система. Идея одновременных запросов обычно слишком расплывчата, чтобы привести к надежному нагрузочному тесту. Обязательно определите запрос, который включает проблемные части приложения. - person Gary; 28.04.2009
comment
Интересный момент — по совпадению — я должен писать наши сценарии нагрузочных тестов прямо сейчас (вместо этого я дурачусь здесь, что веселее). Но определение запроса является критическим. У нас есть очень короткий список вариантов использования, которые важны для нас. - person S.Lott; 28.04.2009
comment
Еще одна довольно распространенная проблема заключается в том, что многие места начинают с создания нагрузочного теста, чтобы увидеть, с какой емкостью они могут справиться в моделируемых производственных сценариях использования. Однако почти всегда происходит то, что они в конечном итоге создают стресс-тест, даже не подозревая об этом. Этот тест взорвет приложение впечатляющим образом. Только после того, как эти ошибки приложения будут исправлены, вы сможете измерить нагрузку на систему. Если вы не проведете нагрузочный/стресс-тест, это сделают настоящие рабочие пользователи, и они не будут довольны. - person Gary; 28.04.2009

arrow_upward
0
arrow_downward

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

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

person Vinnie    schedule 28.04.2009

arrow_upward
0
arrow_downward

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

  1. Нагрузочный тест:

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

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

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

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

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

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

person Satya    schedule 28.04.2009