Por que você configuraria o MaxKeepAliveRequests para algo que não fosse ilimitado?

Question

O KeepAliveTimeout do Apache existe para fechar uma conexão keep-alive se um novo pedido não é emitido dentro de um determinado período de tempo. Contanto que o usuário não feche seu navegador / guia, esse tempo limite (geralmente de 5 a 15 segundos) é o que, eventualmente, fecha a maioria das conexões e evita que os recursos do servidor sejam desperdiçados, mantendo as conexões indefinidamente.

Agora, a diretiva MaxKeepAliveRequests coloca um limite no número de solicitações HTTP que uma única conexão TCP (deixada em aberto devido a KeepAlive ) será veiculada. Definir isso como 0 significa que um número ilimitado de solicitações é permitido.

Por que você configuraria isso para algo que não fosse "ilimitado"? Desde que um cliente ainda esteja ativamente fazendo solicitações, que mal há em permitir que elas aconteçam na mesma conexão keep-alive? Quando o limite é atingido, as solicitações ainda são recebidas, apenas em uma nova conexão.

Do jeito que eu vejo, não faz sentido limitar isso. O que estou perdendo?

    

Answer 1

Basicamente, porque o Apache não foi criado para isso. O problema é o uso da memória do servidor. Em muitas configurações, a geração de conteúdo é feita no mesmo processo que a entrega de conteúdo, portanto, cada processo crescerá até o tamanho da maior coisa que ele manipula. Imagine um processo se expandindo para 64 mb por causa de um pesado script php, e então esse processo inchado está parado e servindo arquivos estáticos. Agora multiplique por 100. Além disso, se houver vazamentos de memória em qualquer lugar, os processos crescerão sem limite.

As configurações de keepalive devem ser balanceadas com base no tipo de seu conteúdo e seu tráfego. Geralmente, a configuração ideal tem MaxKeepAliveRequests alta (100-500) e KeepAliveTimeout baixa (2-5) para liberá-los rapidamente.

    

Answer 2

Eu sei que esta é uma questão antiga, mas eu tenho feito algumas depurações, e parece que (e isso não é verdade apenas para o Apache) MaxKeepAliveRequests funciona independentemente de KeepAliveTimeout .

Ou seja, a diretiva de timeout conta apenas contra conexões persistentes de inatividade (sem leituras ou gravações) - se você continuar solicitando abaixo do tempo limite, poderá fazer virtualmente uma quantidade ilimitada de solicitações na mesma conexão.

Isso pode não ser bom por alguns motivos, incluindo a longa execução de conexões tcp sendo mortas aleatoriamente? Em qualquer caso, os clientes http não são tão estúpidos e podem lidar com uma configuração "baixa" MaxKeepAliveRequests muito bem, por exemplo, é relativamente fácil na linguagem de programação detectar se uma conexão tcp foi fechada pelo servidor e, assim, se reconectar a ela novamente. Além disso, a maioria dos clientes http terá seus próprios limites (por exemplo, os navegadores fechariam uma conexão keep-alive após 300 segundos ou mais).

    

Answer 3

Um motivo seria para o balanceamento de carga. Uma vez que uma conexão persistente keep-alive ou http 1.1 é feita, o balanceador de carga não a moverá para um novo host até que seja fechado. Se você tiver um cliente fazendo um grande número de solicitações em sua conexão, talvez não consiga um bom equilíbrio entre os servidores.

    

Answer 4

Em parte, para impedir que um único usuário monitore todos os slots de conexão. Sem limite, um cliente mal-intencionado ou mal escrito poderia assumir todas as conexões disponíveis e mantê-las para sempre. Isso não é uma grande atenuação para isso, no entanto, comparado a algo como um limite de conexão por IP.

Principalmente balanceamento de carga, mas especificamente no que diz respeito à manutenção. Se você quiser colocar um servidor offline, solte-o em 0 conexões, mas permita que as conexões existentes sejam concluídas por algum tempo. Colocar um limite no número de solicitações de manutenção de atividade significa que, eventualmente, os usuários criarão com graça uma nova conexão e serão movidos para um novo servidor de backend. Provavelmente alguma maneira de sinalizar ao servidor que ele deveria parar de aceitar completamente as atividades de manutenção durante o processo de drenagem seria ainda melhor, mas até onde eu sei, tal recurso não existe.