Na parte 1 deste artigo, discutimos a respeito de como entender o comportamento dos usuários e modelá-lo em linguagem matemática para um exemplo de aplicação de ponto, porém o princípio é aplicado a qualquer aplicação, e o que será de extrema valia para quando terminarmos de avaliar o desempenho da aplicação bem como o hardware necessário, pois este conhecimento compilado em uma planilha Excel nos permitirá amanha, em alguma eventualidade fazer de traz para frente às perguntas que passarão a ser mais freqüentes durante a vida útil do sistema: se eu aumentar em 1.000 usuários o sistema, mantendo a infra-estrutura atual, qual será a degradação esperada que obteremos no tempo de resposta? Se adicionar um passo extra no processo de ponto, como sensibilizar uma segunda base de dados, qual será o impacto para o usuário final, bem qual seria o investimento em hardware necessário, e onde especificamente deverei investir, para que amortize essa degradação no tempo de resposta.
Breve consideração sobre virtualização
Quando estamos falando de visão de futuro em TI, onde se busca a construção de uma infra-estrutura de TI que seja capaz de responder em tempo real, ou seja, que a área de tecnologia seja capaz de definir acordos flexíveis de SLA com as áreas de negócio da empresa que dependem de sistemas, ie. definir um tempo de resposta no sistema para usuários e clientes, e em caso de uma situação atípica como uma campanha que aumente a demando do sistema, um ataque DDOS ou qualquer outro evento de demande muito mais do sistema de que ele estava inicialmente desenhado, isto é, buscar resilience.
Com as tecnologias correntes e disseminadas, todo o sistema repousa sobre um hardware monolítico, a aplicação usa todos os recursos que aquela máquina disponibiliza, faltando ou sobrando é o que está alocado estaticamente para aquela aplicação o que nos coloca em posição de lidar com alguns dilemas do tipo: se eu considerar o dimensionamento de hardware para a pior situação e que sua ocorrência seja esporádica e previsível, como declaração de imposto de renda, promoção, natal, etc. estaremos subutilizando nossos recursos computacionais fora destes picos de uso, porém as tecnologias de virtualização estão quebrando este paradigma, colocando a disposição a possibilidades de alterar dinamicamente a alocação de recursos de máquina (eg. CPU, Memória, I/O de disco e rede).
Mesmo com a virtualização a nossa disposição ainda nos falta entender como usá-la como uma arma de gerenciamento de forma efetiva. O bom dimensionamento de capacidade é fundamental para poder avaliar como dividir o hardware físico em partições lógicas para bom dimensionamento de capacidade, e a modelagem desta compilada nos permitirá tomar melhores decisões quando precisarmos rever o SLA.
No futuro teremos ferramentas mais completas, que analisará o histórico de desempenho e poderá predizer de forma mais completa e avaliando um conjunto maior de variáveis qual é a situação atual e qual será a conseqüência “se” isso ou aquilo acontecer, para melhor guiar na tomada de decisão de alocação de recursos de TI, como é o caso do System Center Capacity Planner 2006, porém ele hoje está restrito somente ao Microsoft Operations Manager e ao Microsoft Exchange Server, não lida ainda com a sua aplicação LOB que sua empresa desenvolveu.
A abordagem que apresentamos aqui é uma alternativa razoável e viável para fazer este trabalho do “what-if” de forma satisfatória, utilizando os recursos de TI atualmente disponíveis no mercado e que nos aproxima um pouco mais do nível de maturidade de infra-estrutura virtualizada dentro do modelo do Gartner. (este pode ser o tópico de outro post).
Analisando a Aplicação
O segundo ingrediente na analise de capacidade é conhecer o comportamento da aplicação sob carga, o que nos interessa neste teste é saber qual é o consumo de hardware para a execução de uma “transação”, e para isso iremos precisar primeiro eleger qual ferramenta iremos utilizar para tal, e como já era de se esperar, neste caso vou utilizar o WAST (MS Web Application Stress Tool), primeiro porque é simples, didático e gratuito, só por isso Depois de definidas as ferramentas, vamos montar o laboratório para analisar a aplicação, e para tanto precisaremos somente de um servidor equipado com caracteristicas semelhantes das que será utilizado na produção, ou seja, se a produção estiver com Xeon 5355 por exemplo, use o mesmo no teste de laboratório, essa é uma recomendação que faço, pois nos dias de hoje, não dá mais para fazer uma simples regra de três com o clock para estimar o desempenho, existe o números de núcleos, o compartilhamento de cache entre os núcles e a microarquitetura do processador que influência no desempenho, portanto a opção de usar o mesmo processador será para eliminar essas variáveis de nossa análise e tornar a “equação” mais simples, o mesmo vale para a configuração de discos e memoria suficiente para não ser gargalo.
Depois do laboratório montado, podemos iniciar os testes de carga sobre o sistema usando o WAST (veja tutorial completo), o resultado final será um relatório gerado pelo WAST em que descreve o resultado do ponto de vista do cliente, ie. quantas requisições ao servidor foram feitas e quantas foram atendidas em qual tempo, quantas não foram respondidas, etc. Outra informação importânte para a nossa análise são os impactos desta carga sobre o servidor, principalmente os seguintes índices:
• Web Service: Get Request/sec
• Web Service: Post Request/sec
• System: % Total processor time
• Active Server Pages: Request/sec
É importante afinar o teste de carga para que o número requisições realizadas pelo cliente não tenham como retorno erros como 404, 400 ou 500, pois significa que o cliente não foi atendido e claramente houveram mais requisições das que o servidor poderia atender, mesmo que o servidor web apresente recursos como CPU, I/O de disco e memória em condição confortável, pois muitos dos problemas que já me defrontei nestas condições apenas escondiam problemas de configuração e ajustes para harmonizar todo o sistema, pois por exemplo: na configuração padrão do IIS, ele permite até 25 threads por núcleo, se a aplicação necessita fazer alguma chamada ao banco de dados ou algum componente externo, aquela thread irá ficar alocada enquanto não houver retorno e a “transação” ser concluida, portanto em casos onde você tenha muitas requisições/segundo e uma lentidão para concluir a “transação”, mesmo tendo CPU disponível, não haverá thread para atender requisições e você receberá um ERRO 500: Server Busy, e portanto será ainda necessário fazer ajustes no IIS para garantir que ele esteja otimizado para as caracteristicas da sua aplicação, para isso recomendo a longa leitura do IIS 6.0 Performance and Tuning ou The Art and Science of Web Server Tuning with Internet Information Services 5.0, porém sem dúvida nenhuma será recompensadora.
Concluindo o teste de carga com sucesso e eliminando todos os problemas de ajustes, será necessário interpretar os dados que temos em mãos. Vamos imaginar hipoteticamente, apenas para trabalhar com um exemplo, que ao final do nosso teste obtivemos o seguinte conjunto de dados:
• System: % Total processor time: 92% na média durante o periodo de testes, com vários picos de 100%. Isso nos permite concluir de forma razoável que houve esgotamente da CPU;
• Active Server Pages: Request/sec: 152, porém para essa aplicação específica, onde é necessário entrar na página, se identificar e selecionar uma ou duas opções antes do POST, requer 8 requisições ASP até completar o processo de “bater o ponto”, portanto temos que é possível neste cenário realizar 19 (152/8) transações por segundo;
Calculando o tempo de resposta
O Teorema Little (LT) define que podemos calcular a capacidade de atender a requisições em uma rede como a razão entre a taxa de requisições sobre a taxa de requisições que podem ser processadas. Se o sistema chega a um ponto onde a razão se torna maior que 1, então nós excedemos a capacidade de atender mais requisições, portanto ou perderemos a requisições (Erro 500) ou teremos que enfileirá-la para ser atendida em algum momento. Portanto podemos com isso definir em que ponto o nosso sistema irá falhar. Se definirmos algum enfileiramento , a razão poderá exceder até o ponto onde houver cache para aceitar requisições, e eventualmente essa razão voltar a ficar abaixo de 1 por tempo suficiente para liberar o cache. Se na média durante o tempo essa taxa exceder a 1, o sistema irá começar a recusar requisições.
A figura abaixo determina o número de requisições que podem ser mantidas na fila e o tempo que uma requisição precisará esperar para ser atendida
Aplicação do LT (λ=taxa de requisição de Poisson, μ=capacidade de processamento de requisições, p=λ/μ ).
É neste ponto onde a probabilidade de Poisson se torna realmente útil. Podemos selecionar a taxa de requisições baseado na probabilidade de multiplos usuários acessarem o sistema simultaneamente, onde só com a média de requisições que encontramos com a curva de Gauss, porém não nos dava o pior caso que é exatamente o que procuramos. Agora podemos prever não só a média de requisições que podemos atender bem como tempo máximo que o usuário precisará esperar para que a requisições seja atendida.
Definindo o Ambiente:
Chegando a esse ponto já temos bastante informação a respeito de como funciona o sistema e como ele se comporta sob carga, portando concluimos a seguinte tabela e seu gráfico correspondente:
Sabemos ainda que pela probabilidade de Poisson, termos 19 usuários simultaneos requisitando o registro de ponto é de 1x10^-14 em termos percentuais, portanto acho que podemos considerar “pouco provável” :) Infelizmente o nosso trabalho muitas vezes não pára por aqui, pois se for necessário dimensionar o sistema para um número maior de usuários, por exemplo, será ainda necessário nos testes de carga determinar se o sistema consegue escalar linearmente com o aumento de processadores/máquinas, o que normalmente ocorre com aplicações stateless, ou se haverá penalidades, o que pode ocorrer em situações onde você tem um banco de dados ou um componentes que represente um gargalo na transação.
Bem… gerenciamento de capacidade é uma tarefa contínua e não existe regras fixas, mas sim boas práticas, das quais procurei nestes dois posts do blog compartilhar um pouco com vocês.
Texto retirado de: http://blogs.intel.com/brasildigital/2007/09/gerenciamento_de_capacidade_pa_1.html
Nenhum comentário:
Postar um comentário