Temos uma máquina Windows Server 2003 executando o Apache2.2. Na maioria das vezes não há carga no servidor, mas temos um programa de notificação no 3400 PC que pode solicitar uma pequena página da Web que reproduz um arquivo .wav de 64 KB. Quando ocorre um evento, todos os 3400 PCs solicitam a página da Web ao longo de 3 minutos. Em algumas máquinas, vimos o navegador ficar no estado "conectando" por um pouco mais de um minuto antes de a página ser pintada. O que está acontecendo e como podemos acelerar isso?
Demora tanto tempo, porque você está realizando um ataque de negação de serviço em seu servidor deficiente.
Por que os computadores precisam buscar o arquivo de áudio de um servidor remoto se o alerta estiver ocorrendo localmente? Eles não poderiam ter uma cópia local distribuída com o aplicativo de notificação?
Eu suspeito que você precise ajustar os valores como topicsperchild para um número muito maior valor para lidar com essa carga. O valor controla o número máximo de solicitações que podem ser processadas de uma só vez.
Existem poucos cenários que mostram claramente a vantagem de um bom servidor da web leve, especialmente um single-threaded. Tente nginx ou lighttpd, tenho certeza que ambos podem estar em conformidade com uma máquina muito menor.
Você tem um número fixo de clientes que você pode atender em um determinado momento. Cada slot é usado pelo período necessário para transferir o arquivo para o seu cliente. Se você tiver 100 slots, e a rede levar 5 segundos para transferir o arquivo (talvez esses computadores estejam atrás de links lentos, discada), você precisará de 175 segundos para atender a todos esses hosts. Você vai olhar para o servidor web e tudo ficará bem - não muita carga de CPU, nem muita carga de disco, nem muita carga de rede. Mas esses clientes lentos estão te matando.
Se o seu ThreadLimit for 64 (ThreadLimit é um limite global), então, iirc, você só poderá atender 64 clientes de uma só vez. A figura leva pelo menos 500-1500 ms para atender cada cliente, você tem um problema de matemática.
Se você puder servir um único cliente em 500 ms, serão 128 clientes atendidos por segundo, ou seja, 27,3 segundos para atender 3500 clientes.
Se você puder servir um único cliente em 1,5 s, são 42,66 clientes por segundo, ou seja, 82 segundos para atender 3500 clientes.
2 segundos por cliente é 54,6 segundos para atender 3500 clientes.
500 ms é provavelmente um cálculo razoável no tempo de configuração do TCP, tempo de solicitação, tempo de transferência, etc, dependendo da latência na rede.
Eu fiz um teste para ver quanto tempo leva para atender a uma única solicitação por vez e depois faço as contas para descobrir quanto tempo levaria para atender a todos se cada solicitação tivesse o mesmo tempo de exibição.
Você provavelmente precisará de um total de 1000 threads prontos para poder exibir esse arquivo em 3,5 segundos.
Além disso, você pode querer ver quanto tempo leva o apache para ativar os threads - se ele mantém apenas 30 threads quando inativo, e a máquina está ociosa até este ponto, então ele tem que girar todos os threads a serem capaz de começar a servi-los. Certifique-se de que seu número mínimo de threads ociosos seja alto.
Editar:
Hmm, fiz alguns testes e parece que você pode esperar um tempo máximo de transferência de 40 ms em algo como uma rede corporativa. Se forem necessários 40 ms para atender um cliente, serão 1600 clientes por segundo, um pouco menos de 2 segundos para atender 3500 clientes.
A próxima melhor resposta que tenho é que a corrida do tráfego está provocando falhas de ethernet. Nós costumávamos ter um servidor web que funcionasse bem durante o dia, mas que se transformaria em lixo à noite. Descobri que nossos backups estavam causando falhas nos uplinks do switch, diminuindo a velocidade do switch. Autonegociação ruim + cabos ruins estavam causando isso.
Tags apache-2.2