Esse tópico do Guj realmente me deixou de cabelo em pé. O usuário em questão perguntou se o hardware que ele tinha em mãos seria capaz de suprir a demanda do sistema dele. Tirando que ninguém de fora poderia dar um veredito honesto sobre o assunto, ele mal sabia como verificar isso! Calcular o hardware necessário para um sistema é algo razoavelmente simples, mas parece que ninguém sabe fazer a conta!
A primeira tarefa para decobrir qual equipamento vai dar conta do teu sistema é descobrir a dimensão dele. Isso inclui total de usuários, volume médio usuários simultâneos e o pico. Depois precisamos levantar a taxa de requisições media e de pico feitas por alguma unidade de tempo. A última coisa necessária são o perfil de navegação de alguns usuários.
No caso de um sistema que já existe, conseguir essas informações é muito simples basta, por exemplo, analisar o access-log do apache. No cenário de ser novo, deve-se valer do plano de negocios do produto e um pouco de inutuição. Essas informações precisam estar quantizadas da forma correta, sempre por uma unidade de tempo comum. Por exemplo, medir o pico de usuários simultâneos por minutos, assim como o de requisições.
Com essas informações em mãos, a primeira coisa a se fazer é conduzir um teste de carga simples e de volume reduzido. O intuito é ter alguma base de medida por onde começar as contas. Esse teste pode ser conduzido entre as estações dos desenvolvedores, não precisa de grande precisão.
Com o números preliminares podemos verificar facilmente quantas máquinas e qual hardware delas vai ser necessário. Por exemplo, o teste indicou que um P4 2.6 sustentou 50 requisições por segundo com qualidade e carga aceitaveis, porém o sistema precisa atingir 200, disso podemos estimar que um máquina com 4 processadores/núcleos deve ser suficiente.
Ao fazer o sizing do sistema, devemos levar em conta fatores como uso de CPU, memória, I/O de rede e discos, além da capacidade de clustering/farming dele. Isso significa que o exemplo anterior está longe de válido, já que não verificamos os demais vetores de consumo de recursos. Memória normalmente é um fator do número de usuários simultâneos (http sessions), número de requisições simultâneas e coisas como caches e buffers. Capacidade dos discos é mais importante para o servidor com o banco de dados que para os demais; e rede para o caso de sistemas distribuidos.
O ideal é com a aquisição do hardware executar um teste de carga mais realista para verificar qual a real capacidade do sistema, para poder planejar futuras expansões no parque assim como validar o processo de sizing.
Medir a capacidade do sistema a principio pode não parecer uma tarefa simples, mas admite um processo bem claro e reprodutivel, então é questão de fazer uma vez e formalizar. Eu poderia dizer que essa receita funciona apenas sob “ceteris paribus”, pois no caso de existirem vários tier, componentes, ou um volume obseno de usuários ou acessos, qualquer maneira de tentar estimar o hardware necessário é muito mais dificil
2 responses so far ↓
1 ASOBrasil // Mar 5, 2007 at 1:25 pm
No tópico do GUJ você diz: “Sem o teste de carga, você vai estar chutando no escuro 100% das vezes, principalmente pq se o teu sistema possuir algum gargalo grande de cpu ou memória, não vai ter hardware que resolva.”! Mas isso (chutando no escuro) geralmente não tem jeito, ou tem? Pois no inicio do projeto você precisa estabelecer qual servidor (hardware) a aplicação vai precisar, pois essa valor tem que ser diluido no custo e no ROI do projeto, correto? Concordo que você faz vários cálculos (citados por você inclusive) para projetar o servidor necessário, mas no geral é um chute (algo aproximado), certo?
2 kumpera // Mar 5, 2007 at 1:36 pm
O problema de estimar o hardware necessário no início do projeto é a imprecisão. Isso tem que ser levado em conta, o cliente deve estar ciente deste fato.
.
Existem basicamente duas formas de resolver esse empasse; o primeiro é adiar essa decisão para quando parte do sistema já existir e pertir que alguma forma de teste de carga seja feito; a outra é estimar usando um histórico de aplicações parecidas.
.
Em ambos os casos a margem de erro vai ser grande, a técnica de usar histórico é boa, mas exige muita disciplina e tempo – afinal, outros sistemas já precisam ter suas medições feitas.
.
O ponto principal é sempre realizar um teste de carga final com o hardware que vai para produção, isso elimina surpresas no caso de servidores sub-estimados.
.
Agora decidir sobre o hardware no começo de um projeto, principalmente sem nenhuma base pela qual decidir, é desperdiçar dinheiro. Se o cliente faz questão disso, ele que assuma o risco.
Leave a Comment