O Apache httpd tem um botão de tempo limite, TimeOut que lida com tempo limite para enviar e receber TCP ações se o cliente não estiver enviando dados para o servidor em tempo hábil (e algumas outras coisas). Isso é fornecido na segunda granularidade e o padrão é 300 segundos. O que isso não fará é tempo limite de uma solicitação que leva 5 segundos para ser processada localmente.
A única fila em httpd é o ListenBacklog para solicitações que Sente-se no socket listen backlog que aguarda para ser atendido por um thread / child de trabalhador do httpd atualmente ocupado. Seu "tempo" de acordo com o Apache não começa até que eles são apanhados por um trabalhador. Você pode usar uma pequena configuração ListenBacklog para que novas solicitações sejam recusadas quando o servidor for iniciado indo devagar. Na verdade, se seus clientes estiverem encerrando a conexão após 200ms, isso provavelmente não importará, já que as solicitações de backlog nunca serão iniciadas corretamente como solicitações http.
As conexões só entram no backlog quando você tem MaxClients ou ServerLimit / ThreadLimit / TheadsPerChild conexões atualmente em uso. Você pode ajustá-los a um nível em que seu serviço seja capaz de sobreviver melhor.
Caso contrário, as solicitações estão sendo manipuladas por um filho / segmento httpd worker e não estão produzindo uma resposta http em < 200ms que eu suspeito é o que você está correndo. Se a resposta for tratada com "em processo" em httpd , não há muito o que fazer além de consertar qualquer coisa que acione o problema. Se você tiver um aplicativo em execução em httpd produzindo as respostas, como ele reagiria se httpd cortasse a conexão? Como o banco de dados, se estiver abaixo, lida com a conexão cortada? Geralmente, eles continuam sem o conhecimento necessário para concluir a solicitação até que tentem e gravem dados em um soquete no final. Lidar com timeouts é algo que precisa ser tratado em sua pilha em cada nível, para que funcione de ponta a ponta.
Nos níveis em que você está falando, acho que você precisaria de algo totalmente diferente de httpd para atender às suas necessidades. Talvez o Mongrel2 com sua distribuição de trabalho baseada em fila pudesse lidar com o timeouts de front end mais facilmente? Talvez um servidor http baseado em eventos possa lidar com os tempos limite ?. Como David menciona, mesmo o TCP poderia ter dificuldades para entregar nos níveis que você está pedindo. O componente TCP da solicitação nem conta para os tempos limite do nível do aplicativo do lado do servidor que você implementa, a menos que você tenha alguns smarts construídos que calculam tempos de ida e volta (o que o http não faz).