Каков наиболее точный метод оценки пиковых требований к пропускной способности для веб-приложения?

Question

Я работаю над предложением клиента, и им необходимо будет обновить свою сетевую инфраструктуру для поддержки размещения приложения ASP.NET.По сути, мне нужно оценить пиковое использование для системы с известным количеством пользователей (в настоящее время 250).Простого ответа типа "вам понадобится выделенная строка T1", вероятно, было бы достаточно, но я хотел бы иметь данные для ее резервного копирования.

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

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

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

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

Платформой является Windows / ASP.NET, а приложение размещено в SharePoint (MOSS 2007).

Answer 1

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

N = Количество просмотров страницы за самый загруженный час P = Средний размер страницы.

(N * P) /3600) = Средний трафик в секунду.

Сам сервер будет иметь намного больше внутреннего трафика, вероятно, для сервера БД / NAS / etc.Но внешний вид этого должен дать вам очень приблизительное представление об использовании.Очевидно, что вам нужно будет намного превысить указанное выше значение, поскольку вы никогда не хотите, чтобы вас использовали на 100%, и разрешить другой трафик.

Я бы также не предлагал использовать произвольное число, например 250 пользователей.Используйте в качестве эталона самый тяжелый производственный день / час.Удваивайте и утроивайте, если хотите, но это даст вам ожидаемое распределение поведения пользователей, если у вас есть хорошие файлы журналов / аудит пользователей.Это поможет сделать ваше предположение более точным.

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

Answer 2

Есть несколько дополнительных вопросов, которые необходимо задать здесь.

Это 250 общих пользователей или 250 одновременных пользователей?Если одновременный, то это 250 пиковых значений или 250 обычных?Если всего 250 пользователей, ожидается ли, что все они будут использовать его одновременно (например, сайт интрасети, где люди должны использовать его как часть своей работы), или это скорее сайт сообщества, где они могут использовать его, а могут и не использовать?Я предполагаю, что, судя по тому, как вы это сформулировали, всего 250 пользователей, но это все равно недостаточно говорит о сайте, чтобы сделать оценку.

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

Что делает сайт?На нижнем уровне спектра находится "типичное" веб-приложение, в котором у вас есть страницы разумного размера (скажем, 1-2 кб) и несколько изображений.Немного более интенсивным является сайт с большим количеством медиа - например, просмотр изображений в стиле flickr.В верхнем конце находится сайт с большим количеством загрузок - потоковые фильмы или просто загружаемые большие файлы или наборы данных.

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

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

Другой вариант, который следует рассмотреть, который фактически позволяет вам полностью избежать всего этого вопроса, - это просто разместить приложение в центре обработки данных.Вы платите относительно низкую ежемесячную плату (низкую по сравнению со стоимостью выделенного высококачественного соединения) и получаете столько пропускной способности, сколько вам нужно (например, большинство тарифных планов хостинга для начала обеспечат вам передачу чего-то вроде 500 ГБ в месяц, а некоторые просто предоставят вам безлимитный доступ).Центр обработки данных также будет более надежным, чем все, что вы можете построить (за исключением вашего собственного центра обработки данных с цифрой 6 +), потому что в нем есть резервный интернет, резервное питание, избыточное охлаждение, противопожарная защита, физическая безопасность..и у них есть люди, которые управляют всем этим за вас, так что вам никогда не придется иметь с этим дело.