Qual é o método mais preciso de estimar pico exigência de largura de banda para uma aplicação web?

Question

Eu estou trabalhando em uma proposta do cliente e eles vão precisar atualizar sua infra-estrutura de rede para suportar hospedar um aplicativo ASP.NET. Essencialmente, preciso para estimar o pico de uso para um sistema com uma quantidade conhecida de utilizadores (actualmente 250). Uma resposta simples como "Você vai precisar de uma linha T1 dedicado" provavelmente seria suficiente, mas eu gostaria de ter dados para apoiá-la.

Outra questão referenciada NetLimiter, que se parece muito escorregadio para obter uma noção do que está sendo usado.

O meu pensamento geral é que eu vou disparar o aplicativo web e usar o sistema como eu iria antecipar-lo ser usado no cliente, na verdade em um ritmo calmo, ao longo de um determinado intervalo de tempo e, em seguida, multiplicar o uso de banda por o número de usuários e dividir pelo tempo.

Esta não parece muito científico. Pode ser bom o suficiente para uma proposta, mas eu gostaria de ver se há uma maneira melhor.

Eu sei que existem ferramentas de carga disponíveis para testar o desempenho dos aplicativos web, mas parece que estes seriam não precisa simular carga de usuário pico para fins de largura de banda teste (muito de uma vez).

A plataforma é Windows / ASP.NET eo aplicativo está hospedado dentro do SharePoint (MOSS 2007).

Answer 1

Em vez de uma boa ferramenta para o uso da banda de relatórios, você pode sempre fazer uma guesstimate áspera.

n = número de páginas vistas em mais movimentado hora P = Tamanho médio página

(N * P) / 3600) = O tráfego médio por segundo.

O próprio servidor terá muito mais tráfego interno para provavelmente servidor db / NAS / etc. Mas voltados para o exterior, que deve dar-lhe uma ideia muito áspera em utilização. Obviamente você precisará superar muito o valor acima como você nunca quer estar 100% utilizada, e para permitir outro tráfego.

Eu também não sugerir o uso de um número arbitrário como 250 usuários. Utilizar o mais pesado produção dia / hora como uma referência. Duplos e triplos, se quiser, mas que lhe dará a distribuição esperada do comportamento do usuário se você tiver bons arquivos de log / usuário de auditoria. Ele vai ajudar a tornar seu guesstimate mais preciso.

Como outro comentarista apontou, um centro de dados é uma boa idéia, quando a redundância e largura de banda disponibilidade tornam-se são uma preocupação. Suas necessidades podem variar, mas não descartar a sugestão de ânimo leve.

Answer 2

Há várias questões adicionais que precisam ser feitas aqui.

É 250 usuários no total, ou 250 usuários simultâneos? Se concorrente, é que 250 pico, ou 250 tipicamente? Se for 250 usuários no total, são todos eles esperavam para usá-lo ao mesmo tempo (por exemplo, um site de intranet, onde as pessoas devem usá-lo como parte de seu trabalho), ou é mais de um site da comunidade onde eles podem ou não use-o? Presumo que a maneira que você redigido este que é 250 o total de usuários, mas que ainda não dizer o suficiente sobre o local para fazer uma estimativa.

Se é uma comunidade ou site na internet "normal", mas também irá depender do uso - por exemplo, são pessoas realmente vai estar usando este intensamente, ou é algo que alguns usuários simplesmente entrar em uma vez e depois esquecer ? Esta pode ser uma pergunta difícil de sua perspectiva, uma vez que você vai querer assumir o primeiro, mas se você gastar um monte de dinheiro em infra-estrutura de rede e há um acaba de usá-lo, ele pode ser uma coisa muito ruim.

O que é o site está fazendo? Na extremidade baixa do espectro, há um "típico" de aplicações web, onde você tem o tamanho razoável (digamos, 1-2k) páginas e um punhado de imagens. Um pouco mais intensa é um site que tem um monte de mídia - por exemplo, o estilo flickr de navegação de imagens. Na extremidade superior é um site com um monte de downloads - streaming de filmes, ou apenas arquivos grandes ou conjuntos de dados a ser transferidos.

Isso está ficando um pouco fora do limite da sua pergunta, mas outra coisa é olhar para o futuro do site: é o uso vai, possivelmente o dobro no ano seguinte, ou mês? Desconfie de bloqueio em um contrato de longo prazo com algo como um T1 ou fibra de conexão, sem ter alguma forma de atualizar.

Outra questão é a confiabilidade - Você precisa de redundância de conexões? Pode custar muito na frente, mas há maneiras de fazer conexões multi-homed onde você pode equilibrar o acesso através de um par de links, e, em seguida, usar apenas um (embora com capacidade reduzida) em caso de falha.

Outra opção a considerar, o que efetivamente permite evitar completamente toda esta questão, é apenas para hospedar o aplicativo em um datacenter. Você paga uma taxa mensal relativamente baixa (baixo quando comparado com o custo de uma ligação de alta qualidade dedicado), e você obter o máximo de largura de banda que você precisa (por exemplo, a maioria dos planos de hospedagem lhe dará algo como 500GB transferir um mês, para começar - e alguns vão apenas dar-lhe ilimitado). O datacenter também vai ser mais confiável do que qualquer coisa que você pode construir (abreviação de seu próprio 6+ figura datacenter), porque eles têm internet redundantes, backup de energia, refrigeração redundante, proteção contra incêndio, segurança física .. e eles têm pessoas que gerenciam todos do presente para você, assim você nunca tem que lidar com isso.