Каков наиболее точный метод оценки пиковой пропускной способности для веб-приложения? - PullRequest
5 голосов
/ 18 сентября 2008

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

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

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

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

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

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

Ответы [ 2 ]

3 голосов
/ 30 декабря 2008

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

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

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

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

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

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

3 голосов
/ 30 декабря 2008

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

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

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...