Esta é uma pergunta canônica sobre o planejamento de capacidade para sites.
Palavras-chave:
Quais são algumas das ferramentas e métodos recomendados de planejamento de capacidade para sites e aplicativos da web?
Sinta-se à vontade para descrever diferentes ferramentas e técnicas para diferentes servidores da Web, estruturas, etc., bem como as práticas recomendadas aplicáveis aos servidores da Web em geral.
Respostas:
A resposta curta é: ninguém pode responder a essa pergunta, exceto você.
A resposta longa é que comparar sua carga de trabalho específica é algo que você precisa se comprometer, porque é um pouco como perguntar "Quanto tempo dura um pedaço de corda?".
Um site estático de uma página simples pode ser hospedado em um Pentium Pro 150 e ainda servir milhares de impressões todos os dias.
A abordagem básica que você precisa adotar para responder a essa pergunta é experimentá- la e ver o que acontece. Existem muitas ferramentas que você pode usar para colocar artificialmente seu sistema sob pressão para ver onde ele se prende.
Uma breve visão geral disso é:
Basicamente, para testar alguma carga, você precisa de algo para testar. Configure um ambiente para testar. Isso deve ser um palpite bastante próximo do hardware de produção, se possível, caso contrário, você ficará extrapolando seus dados.
Configure seus servidores, contas, sites, largura de banda, etc. Mesmo se você fizer isso em VMs, tudo bem, desde que você esteja preparado para escalar seus resultados.
Então, vou configurar uma máquina virtual de potência média (dois núcleos, 512 MB de RAM, HD de 4 GB) e instalar meu balanceador de carga favorito, haproxydentro do Red Hat Linux na VM.
Também terei dois servidores Web atrás do balanceador de carga que vou usar para testar o estresse. Esses dois servidores da web são configurados de forma idêntica aos meus sistemas ativos.
Você precisará de algumas métricas para monitorar, por isso vou medir quantas solicitações chegam aos meus servidores da Web e quantas solicitações posso extrair por segundo antes que os usuários comecem a obter um tempo de resposta de mais de dois segundos.
Também monitorarei o uso de RAM, CPU e disco na haproxyinstância para garantir que o balanceador de carga possa lidar com as conexões.
Como fazer isso depende muito de suas plataformas e está fora do escopo desta resposta. Pode ser necessário revisar os arquivos de log do servidor da Web, iniciar os contadores de desempenho ou confiar na capacidade de geração de relatórios da sua ferramenta de teste de estresse.
Algumas coisas que você sempre deseja monitorar:
Você também pode optar por analisar os impasses do SQL, os tempos de busca, etc., dependendo do que estiver testando especificamente.
É aqui que as coisas se divertem. Agora você precisa simular uma carga de teste. Existem muitas ferramentas que podem fazer isso, com opções configuráveis:
Escolha um número, qualquer número. Digamos que você verá como o sistema responde com 10.000 hits por minuto. Não importa qual número você escolher, porque você repetirá essa etapa várias vezes, ajustando esse número para cima ou para baixo para ver como o sistema responde.
Idealmente, você deve distribuir essas 10.000 solicitações em vários clientes / nós de teste de carga, para que um único cliente não se torne um gargalo de solicitações. Por exemplo, o Remote Testing do JMeter fornece uma interface central para iniciar vários clientes a partir de uma máquina Jmeter controladora.
Pressione o botão mágico Ir e assista seus servidores da Web derreterem e travarem.
Portanto, agora você precisa voltar para as métricas coletadas na etapa 2. Você vê que, com 10.000 conexões simultâneas, sua haproxycaixa está suando muito, mas o tempo de resposta com dois servidores da Web é um pouco mais de cinco segundos. Isso não é legal - lembre-se, seu tempo de resposta está apontando por dois segundos. Então, precisamos fazer algumas alterações.
Agora, você precisa acelerar o site mais de duas vezes. Então, você sabe que precisa aumentar ou diminuir a escala.
Para aumentar a escala, obtenha servidores Web maiores, mais RAM e discos mais rápidos.
Para expandir, obtenha mais servidores.
Use suas métricas da etapa 2 e teste para tomar essa decisão. Por exemplo, se você viu que a latência do disco era enorme durante o teste, sabe que precisa aumentar o tamanho e obter discos rígidos mais rápidos.
Se você viu que o processador estava sentado a 100% durante o teste, talvez seja necessário expandir para adicionar servidores da Web adicionais para reduzir a pressão nos servidores existentes.
Não existe uma resposta certa ou errada genérica, apenas o que é certo para você. Tente ampliar e, se isso não funcionar, em vez disso. Ou não, depende de você e de alguns pensamentos fora da caixa.
Digamos que vamos expandir. Então, decido clonar meus dois servidores da Web (eles são VMs) e agora tenho quatro servidores da Web.
Comece novamente a partir da Etapa 3. Se você achar que as coisas não estão indo como o esperado (por exemplo, dobramos os servidores da Web, mas o tempo de resposta ainda é superior a dois segundos), verifique outros gargalos. Por exemplo, você duplicou os servidores da Web, mas ainda possui um servidor de banco de dados de baixa qualidade. Ou você clonou mais VMs, mas como elas estão no mesmo host físico, você alcançou apenas uma contenção mais alta pelos recursos dos servidores.
Você pode usar este procedimento para testar outras partes do sistema. Em vez de atingir o balanceador de carga, tente acessar diretamente o servidor da Web ou o servidor SQL usando uma ferramenta de benchmarking SQL .
O planejamento da capacidade começa com a medição, neste caso, tempo de resposta versus carga. Depois de saber o grau em que os programas ficam mais lentos com a carga, o que NÃO é uma função linear, você pode selecionar uma meta de tempo de resposta e descobrir quais recursos serão necessários para atingir essa meta em uma determinada quantidade de carga.
A medição do desempenho é sempre feita com unidades de tempo , como
Coisas como% CPU e IOPS são específicas do sistema; portanto, você as usa somente quando planejou o sistema e o mediu na pré-produção, para atuar como um "substituto" para o que interessa, o tempo.
O planejamento de capacidade é um animal problemático. É tanto ciência quanto arte (se definitivamente uma obscura).
Seu melhor argumento é que você tome decisões bem informadas e a sorte / sorte o favorece, fazendo com que a realidade atenda às suas suposições. Se sua capacidade precisa de suposições que correspondam à realidade, você parece um iogue místico. Infelizmente, se suas suposições excederem a realidade, você parecerá ter ultrapassado e ultrapassado. Infelizmente, se suas suposições estão abaixo da realidade eventual (ou estão incorretas), você não terá a capacidade necessária e terá que se esforçar para mitigar as falhas de sua infraestrutura de gemidos, o que faz parecer que você não tem competência.
Sem pressão ...
Infelizmente, a arte sombria do planejamento de capacidade é mais do que pode ser razoavelmente destilada em uma única resposta de falha do servidor; realmente, é um tópico digno de livros.
Felizmente, existe um livro como esse: " A arte do planejamento de capacidade "
Para expandir a postagem de Mark Henderson, estou escrevendo isso específico para o Apache. Para reiterar o que ele disse: "A resposta curta é: ninguém pode responder a essa pergunta, exceto você". O texto desta resposta é muito emprestado da minha resposta para uma pergunta semelhante sobre o desempenho de um site Drupal .
O Apache é sem dúvida um dos (se não o) servidor web mais popular disponível. É de código aberto e ainda é mantido ativamente. Você pode executá-lo nos sistemas operacionais Linux e Windows, mas é mais popular no mundo Linux / Unix.
Você nunca deve usar uma configuração Apache pronta para uso. Você sempre precisa ajustar o Apache ao seu site. O principal arquivo de configuração do Apache no CentOS está localizado em /etc/httpd/conf/httpd.conf, e o principal arquivo de configuração do Apache nos sistemas Ubuntu geralmente está localizado em /etc/apache2/apache2.conf. Arquivos de configuração adicionais são usados para coisas como hosts virtuais .
Como muitos softwares, o Apache foi desenvolvido para ser flexível e personalizado de acordo com as necessidades de um site específico. Existem diferentes módulos de multiprocessamento que o Apache pode ser configurado para ligar a uma porta de rede e aceitar e processar as solicitações.
Na maioria das vezes, nas instalações padrão do Apache que acompanham os servidores CentOS e Ubuntu, o MPM " mod_prefork " é usado. Supondo que você esteja usando o mod_prefork (se você não tiver certeza, é mais provável, mas apenas você pode determinar isso) Aqui está o básico de como configurá-lo:
MaxClients& ServerLimitvariáveis.Essa certamente não é a resposta definitiva. O ajuste do servidor Apache leva tempo e requer experiência para ficar perfeito.