Reduzindo o enfileiramento de pedidos do Apache

5

Na New Relic, uma das métricas exibidas como parte do tempo de resposta do aplicativo é "Request Queue".:

To collect request queuing time, you need to mark the HTTP request with a timestamp when queuing starts. [1]

Isso é feito adicionando um cabeçalho HTTP no httpd.conf do Apache:

RequestHeader set X-Request-Start "%t"

New Relic menciona que:

For the request queuing bucket, a site operator can provision more application instances.

No entanto, vimos a adição de novas instâncias de aplicativo (ou seja, nós da web) não afeta o tempo de enfileiramento da solicitação - ele permanece constante. Estamos vendo isso medido em cerca de 250ms.

Quais fatores afetam o tamanho da fila de solicitação e como ela pode ser reduzida?

[1] link

    
por DavidM 07.06.2011 / 03:46

2 respostas

7

Acho que a melhor maneira de fazer isso é aumentar os parâmetros 'Server Limit' e 'Max Clients' no Apache Config

Isso determina quantos segmentos o Apache pode processar simultaneamente. Se você tiver um valor de '100 clientes máximos' de 100, o Apache pode processar até 100 solicitações ao mesmo tempo.

Provavelmente, também é importante notar que o Apache é bom para arquivos pequenos (texto, talvez CSS / JS etc.), mas não tão bons em arquivos maiores como imagens, vídeo, flash, etc. request (A menos que você esteja usando Keep-alive, mas isso não melhora muito). Portanto, se você tiver uma página com 49 recursos externos (so 50 pedidos no total) que leva 1 segundo para carregar e seus clientes máximos estiverem definidos como 100, só será possível processar duas exibições de página por segundo antes que os pedidos sejam enfileirados.

Você pode contornar isso de várias maneiras, tente descarregar seu conteúdo em um CDN (o preço começa em cerca de US $ 0,10 / GB, mas se a transferência de dados for alta, talvez valha a pena entrar em contato com a Edgecast ou Akami. muito mais barato a granel). Isso significa que seu servidor não precisa se preocupar com nenhum dos recursos estáticos necessários para carregar uma página. Portanto, em nosso exemplo acima, você tem até 100 exibições de página por segundo antes de as solicitações começarem a ser enfileiradas.

Se você não quiser desembolsar em um CDN, sugiro obter dois IPs em seu servidor e anexar um ao Apache e outro ao NGINX. O NGINX é um servidor de desempenho muito alto, capaz de lidar com milhares de vezes mais conexões do que o Apache, o NGINX não usa enfileiramento de pedidos, como o Apache, porque não bloqueia. Infelizmente o NGINX não possui todos os recursos do Apache, você não pode, por exemplo, rodar o PHP diretamente via NGINX sem fazer proxy para o Apache / FCGI / HipHop, etc.

Como um complemento a isso, na sua pergunta você diz "nós da Web", estaria correto em pensar que você está usando o Apache como um servidor proxy / balanceador de carga de front-end para esses nós? Se assim for, eu sugiro que você teste algo como NGINX, Varnish, HAProxy etc., pois eles são muito mais adequados para fazer coisas assim e lidar com conexões simultâneas.

-
EDIT:
Eu pensei que isso poderia interessá-lo no que diz respeito aos servidores frontend LB.
Estávamos usando o Apache como um proxy de frontend para 16 nós de aplicativos divididos em dois servidores. O servidor proxy estava sendo executado em um servidor Intel Core i5 de quatro núcleos (de modo algum sob especificação). Começamos a perceber uma relação parabólica entre o número de solicitações / segundo e o tempo de resposta. Com cerca de 2000 solicitações por segundo, a carga da CPU dispararia e cada resposta levaria cerca de 800ms para ser concluída. Em 3.000 r / s, cada resposta levaria cerca de 2 segundos. Nós mudamos para o NGINX e atingimos 5000 r / s enquanto apenas adicionamos cerca de 50ms de média à latência e a carga de CPU era um quarto do que era com o Apache.
Obviamente, isso depende inteiramente da sua situação, do que você está fazendo e de quais recursos você tem disponíveis, mas eu apenas pensei em dar a minha opinião sobre isso =)

    
por 17.06.2011 / 10:37
0

Eu tenho que fazer a pergunta óbvia: a documentação afirma que você deve usar o cabeçalho http X-Queue-Start (ou X-Queue-Time), mas você mencionou que está usando o X-Request-Start. Você está adicionando o cabeçalho correto?

    
por 23.06.2011 / 06:06