Olá
Capacity planning ou planejamento de capacidade é uma arte as vezes chamada de “black magic” e geralmente muito bem remunerada porque depende de muita experiência para analisar os inúmeros fatores e avaliar se vamos atender aos níveis de serviço de contrato. O servidor de aplicações é apenas um dos fatores. Por exemplo: o tomcat 5 funciona perfeitamente em um Pentium 166 com Linux. Tenho um ao meu lado assim. Mas não tem a responsabilidade de atender 40K consultas /dia com cinco noves de disponibilidade, principalmente consultas do tipo tudo ou nada que precisam ser desfeitas em caso de falha em alguma camada.
[list=1:928b80dc9c]Introdução ao planejamento de capacidade x níveis de serviço
Exemplos de níveis de serviço
- Limites superiores no tempo de resposta de uma requisição, exemplo: abaixo de k segundos responde tudo, entre k e l, perde 50%, acima de l perde 90%;
- Taxa de processamento mínima do servidor (throughput), exemplo: no mínimo n transações por segundo;
- Disponibilidade mínima do site, exemplo: site disponível pelo menos 99,9% de todo o tempo (neste exemplo apenas 3 noves);
- Percentual de transações com tempo de resposta abaixo de um certo valor, exemplo: 95% das transações não devem ser respondidas em mais de k segundos.
Quando qualquer um dos níveis de serviço for violado diz-se que a capacidade do sistema atingiu o ponto de saturação.
Gargalo de um sistema é o componente por onde a transação gasta a maior parte do seu tempo. As melhorias no tempo de resposta são limitadas pelo tempo gasto no gargalo.
O planejamento da capacidade é o processo de prever quando os níveis futuros de carga saturarão o sistema e determinar o modo mais econômico de adiar a saturação do sistema ao máximo possível.[/list:o:928b80dc9c] Feita esta introdução vamos voltar à sua dúvida. Você falou em sistema de 3 camadas e nem disse quais seriam estas camadas. Mas vou chutar que uma camada seja de persistência. Se esta camada usar banco de dados já pode mudar todo o panorama. Ainda chutando pensei com meus botões que um sistema com 40K consultas /dia talvez precise de uma certa redundância, talvez de balanceamento de carga e até mesmo de alta disponibilidade. Como vê o negócio vai longe. E olha que nem avaliei se o tomcat 5.0.19 que é um bom servlet container e um péssimo web server pode ou não atender ao seu problema. Por exemplo, se vai usar EJBs vai precisar de algo como o JBoss, WebSphere, WebLogic, Orion Server ou muitos outros.
Só para que você perceba como seus dados são insuficientes lhe digo que participei de um projeto com picos de 300K transações/dia, throughput de contrato 200tps, onde haviam 4 servidores RISC top de linha cada um com 12 processadores e 16Gb de memória. Um par de servidores para a camada dos servidores de aplicação com balanceamento de carga e o outro par para a base de dados. Tudo com alta disponibilidade. A base de dados é paralela com os dados armazenados em SAN acessada por gigabit.
Vou lhe indicar alguns links sobre capacity planning que é uma área onde imagino que possa me dar alguma graninha:
Web Capacity Planning: How to Plan for Server Growth
Capacity Planning for Web Services: Metrics, Models, and Methods, 2nd Ed.
Os fornecedores do tipo Oracle, IBM, etc. também tem lá suas ferramentas para ajudar a planejar a capacidade.
Mais alguns outros links googlados:
http://dspace.dial.pipex.com/regday/
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci762219,00.html
http://www.nwfusion.com/news/2001/1029specialfocus.html
http://www.specbench.org/osg/web99/
E como o louds bem disse, nada como alguns benchmarks do seu próprio problema. Há ferramentas free como o JMeter por exemplo ou se seu orçamento comporta contrata logo a Mercury.
Persistindo os sintomas … estamos aí.
[]s
Luca