É comum colocar um servidor da Web com mais recursos na frente de um servidor de aplicativos, especialmente para exibir conteúdo estático e definir redirecionamentos / regravações. Como regra geral, é uma boa ideia minimizar o número de dependências que você tem em seu back-end do servidor de aplicativos. O conector AJP é mais otimizado para esse caso de uso específico, pois transporta o tráfego com proxy por meio de um transporte binário otimizado.
Sinta-se à vontade para comentar o conector se não for usá-lo e não se sentir compelido a mudar seu ambiente de produção para alavancar a AJP se as coisas estiverem funcionando bem. Eu fazer parece lembrar algumas dores de cabeça de configuração menos do que óbvias com httpd que pode ser executado quando o proxy AJP em vez de HTTP. Já faz alguns anos desde a última vez que fui um administrador do Tomcat, infelizmente, não posso oferecer detalhes específicos.
Se parecer que os administradores do servidor são alérgicos a permitir que o servidor de aplicativos manipule mais conexões do que o estritamente necessário, você não se enganaria. Há várias razões comprovadas para isso:
- Desempenho. O software de servidor da Web dedicado é geralmente muito melhor otimizado para a entrega de conteúdo estático fora do sistema de arquivos. Suas implementações multitarefas são quase inteiramente dedicadas a isso. Pode não parecer uma grande economia para você, mas quando você começa a lidar com milhares de solicitações por segundo, a sobrecarga faz a diferença.
- Menos estado para acompanhar. Servidores Webapp estão sobrecarregados com muito mais que precisam para manter o controle em seu estado de memória. O consumo de memória por solicitação é normalmente muito menor para o servidor da Web dedicado, e esse estado é, na maioria das vezes, descartável: os processos filhos são reciclados com freqüência quando terminam de atender a uma solicitação. Também faz pouco sentido que o código orientado a conexão seja executado toda vez que o aplicativo precisar servir um arquivo. (código desleixado acontece, intencionalmente ou não)
- Isolamento do processo. Esta é uma coisa muito maior do que a maioria das pessoas imagina. Se o seu contêiner tiver problemas de uso (geralmente o Java está ficando sem memória), a extensão da sua quebra é diminuída. Isso é particularmente importante se a sua empresa não conseguir financiar um bom conjunto de balanceadores de carga que retirem automaticamente o webapps com defeito do pool de serviços.
Em suma, os administradores tentam evitar "complicar demais" as coisas, não permitindo que o servidor de aplicativos manipule tarefas que eles não precisam. Pode parecer que eles estão tornando as coisas mais complicadas por levantar uma camada adicional de processos, mas na prática as coisas funcionam da melhor maneira possível.