Parâmetros do Apache / Tomcat

3

Eu tenho um servidor Medium no EC2. Eu não sei muito sobre Apache ou Tomcat - eles estão funcionando, mas além disso eu não tenho conhecimento avançado de como mexer. Eu sei que posso definir o tamanho mínimo / máximo da JVM para o servidor Tomcat e que posso definir quantos segmentos o Apache pode separar, mas não sei quais são os valores "razoáveis" para esses parâmetros.

  1. Sei que a resposta é subjetiva, mas existem configurações comuns com as quais devo começar?
  2. Existe uma maneira simples de carregar / testar o desempenho do meu aplicativo?

Obrigado.

EDITAR:

O sistema é um meio EC2:

Instância média de alta CPU:

  • 1,7 GB de memória
  • 5 unidades de computação do EC2 (2 núcleos virtuais com 2,5 unidades de computação do EC2 cada)
  • 350 GB de armazenamento de instâncias
  • plataforma de 32 bits
  • Desempenho de E / S: moderado
  • nome da API: c1.medium

Os únicos serviços que estou executando são o Apache e o Tomcat. Nada mais está no servidor.

    
por skaz 26.08.2011 / 01:35

3 respostas

4

Apache

Confira a documentação do Apache, ele entra em mais detalhes do que eu poderia aqui:

link

JVM

Defina o Xmx da JVM para não mais que 70% (aproximadamente) do total de RAM física livre. A razão para isso é que as bibliotecas perm gen e JVM ocupam espaço adicional também - o objetivo é que a memória total do processo nunca use memória virtual / swap. Se você definir isso muito alto, começará a ver problemas como "limite de sobrecarga de GC excedido".

O seu algoritmo GC pode ter um grande efeito no desempenho - certifique-se de estar usando alguma forma de coletor paralelo e não a serial 'pause, mark and sweep'. A JVM geralmente faz isso para você automaticamente no modo -server .

Use uma ferramenta como JConsole ou JVisual VM para inspecionar o GC e a quantidade de heap que você está realmente usando e ajustar para baixo - um heap muito grande pode afetar os tempos de coleta de lixo.

Tomcat

Quanto aos encadeamentos de conectores HTTP, em uma única instância do Tomcat, dependendo do seu aplicativo, normalmente você pode aumentar a contagem de encadeamentos para cerca de 600 antes de encontrar problemas - no entanto, não há necessidade de ser tão alto assim ' Vou apenas colocar mais pressão na CPU e na memória.

Quando estiver satisfeito com os tópicos máximos, defino os minSpareThreads e maxSpareThreads em relação a isso. Aumentando os valores se eu souber que vou ser atingido por picos em novas conexões, etc.

Próximo passo acceptCount . Este é o máximo de conexões enfileiradas -c onnections que transbordam essa configuração após o uso dos encadeamentos do conector receberão uma "conexão recusada".

Como um tweek menor, você pode definir enableLookups (permitir pesquisas de nome de host DNS) para false. Quando ativado, (ligeiramente) afeta negativamente o desempenho.

Além disso, confira a Biblioteca nativa do Tomcat, isso usa código nativo para melhorar o desempenho em certas operações (como IO de arquivos, etc.).

Teste de carga

Para testes básicos de carga / desempenho, confira o Apache JMeter:

link

Nós o usamos para testar o desempenho básico do carregamento da página, com scripts de teste do JMeter usando centenas de solicitações simultâneas. Você precisa de um servidor razoavelmente robusto para executá-lo (não na mesma máquina em que você está executando o Apache HTTPD e o Tomcat).

    
por 26.08.2011 / 16:44
1

Heap, gostaria de definir ms = mx = 1GB inicialmente. 1.5 se você estiver com fome de memória. Eu nunca vi nenhum ponto (ou ganho) em ter um tamanho de heap variável em um ambiente de servidor.

O tamanho do pool de threads é um capítulo só dele. Eu estou falando sobre o Tomcat aqui, principalmente.

Se o seu aplicativo tiver muitas seções sincronizadas (caches compartilhados, recursos externos / integrações com apenas acesso serial e outras coisas), os threads de trabalho terão um retorno decrescente, pois quanto mais eles forem, mais tempo eles passarão esperando por cada um deles. de outros. Com suas especificações e sem saber nada sobre o seu aplicativo, direi 50 como ponto de partida em termos de tamanho do pool de threads. Você precisará executar alguns benchmarks de desempenho para ajustar isso corretamente. Use o jmeter, por exemplo, e crie um script de teste que emula um ou alguns dos principais casos de uso em seu site. Use 2 ou 3 instâncias temporárias do EC2 como geradores de carga (você só precisará deles por um curto período) onde você executa o aplicativo jmeter-server.

Execute cenários de teste com permutações de, por exemplo, 60, 120, 180 e 240 threads de solicitação jmeter e 30, 50, 70 e 90 threads de trabalho tomcat. Compare tempos de resposta e uso de CPU e memória em seu servidor. Para informações básicas de CPU / memória, você pode usar as informações padrão de jconsole ou visualvm fora de sua JVM. Também é possível executar sua JVM do tomcat com coleta de lixo detalhada (registro de lixo do GC) e estudar a memória e o comportamento do GC com algo como tagtraums visualizador de GC .

    
por 26.08.2011 / 15:59
0

um valor inicial razoável é 25% do tamanho novo (Xms) comparado ao total do heap (Xmx)

Sugiro que você crie um perfil para seu aplicativo com base no pico de carga e observe a utilização da memória usando o LambdaProbe ou similar e veja o que precisa mudar

    
por 26.08.2011 / 07:35