Estamos construindo uma aplicação J2EE. Ela esta dividida em:
Módulo Web (JSF);
Módulo EJB;
Banco Postgres;
Gostaria de saber como posso ter uma noção de requisitos de máquina (processador, memória, banda de rede…) para implantar esta aplicação considerando um tráfego de page views de 4.000.000/mês. Não necessariamente uma máquina somente, mas considerando estes números, como saber quantas máquinas seriam necessárias em um cluster?
A quantidade de page views por mês não diz nada de como deve ser a performance, você tem que medir pelos picos de acesso ao sistema, como 10000 clientes simultâneos.
Cada aplicação é um mundo, não é possível medir a máquina necessária sem ter o sistema rodando e colocar ele pra ser testado, o que você tem que fazer é, junto com os testes unitários e de integração, criar um conjunto de testes de performance e avaliar como a aplicação se sai no hardware que você está usando, aí, você vai ver se você tem o suficiente ou precisa de mais.
A natureza da aplicação com certeza influencia e bastante. Estamos realizando tunning nela por meio do JMeter (testes de carga) e JProfiler (consumo). Mas considerando-se por exemplo Tomcat e JBoss, qual seria uma média de limite de cada um? Tem alguma idéia? Estou tentando criar uma estimativa de uso diário ainda.
Complementando…
Estamos estimando 1.000.000 de usuários inicialmente:
Divididos em 30 dias -> 33400 U/Dias
Divididos em 8h horas -> 4175 U/Hora (VEJA PORQUE 8 ABAIXO)
Divididos em 60 min -> 70 U/min
Observe que usei 8h e não 24h no dia! Isso porque considero os pontos de pico da aplicação:
08:00h as 10:00h
12:00h as 14:00h
20:00h as 24:00h
Pra evitar um desvio acabei considerando estas dados. Bem isto é que tenho inicialmente, não sei se estou certo. De qualquer forma vou montar os testes com base nestes valores. Se tiver alguma sugestão ou dica manda ver.
É isso que eu estou falando, você está estimando 70 usuários “por minuto”, mas isso não é uma estimativa real, você não vai ter um usuário chegando, fazendo uma requisição e depis entrando outro usuári. Você vai ter diversos usuários acessando ao mesmo tempo e é isso que você deve medir.
Quantos usuários você quer ser capaz de responder de forma concorrente? 10? 100? 1000?
E em quanto tempo você quer tratar todas essas requisições? Quer responder 100 por segundo? 1000 por segundo?
Quais são as páginas mais críticas? Você mantém muidos dados na sessão ou a aplicação é “stateless” (se ela for stateless a maior parte do seus problemas de performance estariam resolvidos)?
Mais uma vez, não dá pra dizer que “vai aguentar um milhão”, você tem definir uma meta e tentar chegar a ela, não tem muito pra onde correr não, cada aplicação é um mundo.
Outra coisa, se a sua aplicação for só web, não tiver nada que só possa ser feito com um servidor de aplicação, prefira um servidor mais leve como o Jetty em vez do Tomcat, ele ocupa bem menos memória e é bem mais rápido. Também é interessante, dependendo de o que seja o seu site, usar uma CDN (content delivery network) pra recursos estáticos, como arquivos de CSS, imagens, js e essas coisas que não mudam com muita frequência, assim você tira esse peso dos seus servidores.
Eu tenho usado o S3 da amazon pra isso a algum tempo e não tenho reclamações.
Um parâmetro fundamental para este tipo de análise e que vc. não mencionou é o tempo de resposta esperado na HMM (hora de maior movimento).
A partir daí vc. pode começar a usar um pouco de teoria de filas para chegar a uma estimativa. Um erro típico é assumir que uma máquina com o dobro de recursos pode atender o dobro de tráfego. Isto só seria verdade se os sistemas escalassem de forma linear, mas o que normalmente se vê é um aumento logarítmico, em função de fatores como concorrência e da própria natureza estatística da distribuição de chegada.
De toda forma, o ponto de partida é um teste de carga em um ambiente conhecido e devidamente intrumentado para que vc. possa decompor seu tempo de serviço nos vários fatores componentes: tempo de transmissão de dados, lógica de aplicação, acesso a banco, etc.
Existem produtos comerciais que fazem esta quebra e a exibem de forma gráfica (ex: dynaTrace) e, com alguma pesquisa, talvez vc. tb encontre algo free. Outra dica é dar uma olhada em pacotes de AOP, que permitem que a injeção de “probes” no código sem ter que recompilar nada.
Storage
$0.15 per GB-Month of storage used
Data Transfer
$0.100 per GB - all data transfer in
$0.170 per GB - first 10 TB / month data transfer out
$0.130 per GB - next 40 TB / month data transfer out
$0.110 per GB - next 100 TB / month data transfer out
$0.100 per GB - data transfer out / month over 150 TB
Requests
$0.01 per 1,000 PUT, POST, or LIST requests
$0.01 per 10,000 GET and all other requests*
* No charge for delete requests [/quote]
Isso se aplica pra nós no Brasil???
Você tem uma estatística sua e o preço que paga pelo serviço, para termos idéia?