Práticas recomendadas para o benchmarking de servidores da Web

3

Eu tenho um servidor da Web que desejo testar antes de fazer algumas otimizações para ver se eles têm algum efeito.

No entanto, quero saber quais são as melhores práticas de benchmarking?

Por exemplo, um colega de trabalho me disse para comparar a máquina com outra máquina em uma rede local para eliminar problemas de tráfego de rede.

No entanto, eu estava pensando em usar uma máquina off-site como referência, porque queria ver se as otimizações fariam alguma diferença em um caso do mundo real.

Eu estava argumentando que muitos dos ajustes de velocidade lidam com a otimização da conexão de rede. Por exemplo, no Apache, o valor KeepAlive permite que os navegadores usem uma única conexão TCP para solicitar vários objetos, em vez de abrir e fechar uma conexão para cada recurso.

Se o teste foi feito em uma conexão de rede local, esse ajuste não faria muita diferença, certo? O mesmo com minimizar js / css e remover espaços em branco / comentários de HTML.

Por outro lado, vejo o problema com o tráfego da Internet, fazendo com que o benchmark não seja consistente. Eu realmente não saberia se as alterações nos números são dos ajustes ou se os servidores intermediários tinham cargas maiores ou menores.

Quem está certo? Qual é a melhor prática para benchmarking? Devemos fazer as duas coisas?

tl; dr - Devo fazer benchmark usando uma máquina na rede local / fora do local / ou em ambos?

    
por rlorenzo 04.11.2010 / 18:54

2 respostas

2

Tudo depende muito do seu site. Fazer benchmarks off-line e on-site não vai doer. Mas, o que ajustar e como testar?

Se você está servindo principalmente conteúdo estático ou algum conteúdo dinâmico simples muito e fazendo isso a uma taxa insana, então ajustes no tempo limite do Apache / nível do kernel fazem sentido.

Se você tiver um site dinâmico, os ajustes muito em breve se tornarão uma besta diferente. Claro, fazer todas essas otimizações no nível do kernel e do Apache ainda é uma coisa sensata a ser feita, mas não seja enganado e espelhado por elas.

Quando se trata de ajustes / testes de desempenho, sempre primeiro cuide das partes mais lentas. Com um site dinâmico, o gargalo real é provavelmente 1) o banco de dados ou 2) os scripts que seu site está executando.

Se a parte mais lenta for o banco de dados, não faz sentido ajustar o desempenho do seu Apache antes que você possa tornar seu banco de dados mais rápido. Além disso, você precisará ter certeza de ter as técnicas de cache adequadas e executar o memcached ou semelhante, se possível.

Então, foi sobre o que avaliar e ajustar. Agora, como é o benchmark?

Eu gosto de executar dois tipos de benchmarks. Se os números já são conhecidos - digamos, um site está recebendo uma reformulação, para que você conheça visitantes únicos, carregamentos de página e estatísticas semelhantes do site antigo -, eu executo um benchmark realista com taxa semelhante ao site atual. Eu também o benchmark com uma taxa similar * 2 para ver se ele pode suportar um pouco do crescimento futuro.

O outro tipo de referência que gosto de usar é fumar e queimar o site. Vou apenas torturar o inferno fazendo benchmark o mais rápido possível com quantidades insanas de solicitações simultâneas. Se puder aguentar, ótimo, se não puder, acho qual é o ponto de ruptura.

Ferramentas que eu gosto: ab, siege, JMeter.

    
por 04.11.2010 / 19:13
0

Eu usei um formato de log personalizado com o% T (tempo de serviço) especificado em uma base contínua. se eu substitui% l (nome do identificador) no formato. Isso pode ser usado para identificar páginas lentas para ajuste. Respostas grandes em linhas lentas podem causar falsos positivos, assim como novas tentativas de rede.

Eu usei um script de resumo de log personalizado para identificar páginas com respostas mais lentas e tempo médio de resposta. Estes podem ser bons alvos para otimização. Comparar os relatórios ao longo do tempo ajuda a identificar os problemas futuros.

As ferramentas do lado do cliente podem fornecer bons benchmarks de estresse e verificar correções que não quebraram o site. Existem fatores que podem fornecer benchmarks que não correspondem ao que você obtém na produção.

    
por 05.11.2010 / 05:31