Todas as soluções comet dependem de manter a conexão entre o servidor web aberta o maior tempo possível, seja pelo cliente fazendo uma solicitação POST e atrasando o envio dos dados, ou o servidor enviando uma resposta GET , atrasando novamente os dados.
Ao colocar um proxy reverso como o Apache na frente do Jetty, como o apache, cada conexão aberta entre o Jetty e o cliente também consumirá um trabalhador. Dependendo do modelo de trabalho do apache escolhido (por exemplo, mod_prefork ou mod_worker_mpm ), haverá limitações no número máximo de conexões que seu servidor apache pode suportar. Isso é em torno de algumas centenas por mod_prefork e é geralmente limitado pela quantidade de memória física consumida por cada processo de trabalho, para alguns milhares com mod_worker_mpm . Se você está misturando mod_worker_mpm com php você deve pesquisar as opções com as quais sua versão do php foi compilada, pois há incompatibilidades conhecidas com php e mod_worker_mpm .
Você também precisará estar ciente dos tempos limite no Apache e no Jetty. As conexões de estilo Comet simulam uma solicitação POST lenta, portanto, você precisará ajustar o Apache para torná-lo mais tolerante, assim como o tamanho do corpo da solicitação. Solicitações de GET style também estão sujeitas a tempo limite se nada for transmitido do servidor de origem. Você terá que aplicar esses tempos limite em ambos os lados da conexão de proxy reverso, do cliente para o Apache e do Apache para o Jetty.
Se eu estivesse implantando uma solução como essa, colocaria o serviço do Comet baseado em Jetty em um domínio diferente, usando um balanceador de carga para fazer proxy de vários back-ends do Jetty para capacidade e confiabilidade adicionais ou usaria outro proxy reverso, digamos HAProxy, para agir no lugar do Apaches, e direcionar solicitações para os vários backends (Apache, Jetty), com base na URL.