Nous avons un serveur frontal Tomcat qui est utilisé par notre serveur d'application Apache 2.2.11, fonctionnant sur une instance Fedora 2.6.21.7 EC2 2xlarge (AKI aki-b51cf9dc). Apache exécute mod_perl et n'est pas threadé.apache2 ignore MaxKeepAliveRequests, ferme les connexions arbitrairement
Nous essayons de faire durer les connexions pendant longtemps entre Tomcat, s'exécutant sur une autre instance EC2, et le serveur Apache, tout en ne conservant pas les connexions des clients externes arrivant directement sur le serveur Apache. Notre configuration ressemble à ceci:
Listen 80
NameVirtualHost *:80
# used for external clients
<VirtualHost *:80>
ServerName xxx.yyy.com
ServerAlias *.yyy.com
DocumentRoot "/var/www/html"
KeepAlive Off
</VirtualHost>
# used from tomcat server on local network
<VirtualHost *:80>
ServerName ip-<Apache-server-local-IP>.ec2.internal
KeepAlive On
KeepAliveTimeout 3600
MaxKeepAliveRequests 0
DocumentRoot "/var/www/html"
</VirtualHost>
TimeOut 60
MinSpareServers 20
MaxSpareServers 30
StartServers 20
MaxClients 60
GracefulShutdownTimeout 90
Nous avons essayé toutes sortes de valeurs pour MaxKeepAliveRequests et KeepAliveTimeout, et le serveur maintient certainement une connexion pendant un certain temps avec Tomcat, mais il ferme toujours en quelques secondes, quand seulement quelques dizaines de demandes ont été traitées. Il peut être significatif que je n'ai jamais vu un processus maintenir 100 connexions ou plus sur un socket tout en observant l'utilisation de mod_status.
Il n'y a jamais de connexions permanentes avec les clients non-Tomcat, donc nous savons qu'il y a une différence et la configuration de VirtualHost est définitivement appliquée dans les deux cas.
Je dois mentionner que les requêtes de Tomcat sont toutes des POST alors que les autres sont un mélange de POST et de GET. Quand je regarde le trafic sur un port donné avec tcpdump je peux clairement voir un certain nombre de POST en cours de traitement, puis à un moment donné après avoir renvoyé une bonne réponse (200, les données semblent bonnes) le serveur Apache ferme immédiatement le connexion, envoyer un FIN à Tomcat. Cela arrive dans les cas où il n'y a absolument aucune différence entre la dernière et l'avant-dernière requête ou réponse autre que des données mineures comme l'IP du client réel, donc il n'y a aucune indication de barfing du serveur lors du traitement d'une requête. Et bien sûr, il n'y a rien de suspect dans les journaux d'erreurs et les processus httpd eux-mêmes ne meurent pas. De netstat, nous pouvons voir les connexions au serveur Tomcat rester ouvertes pendant quelques secondes, mais cycler assez rapidement à travers la gamme de ports distants, vérifiant ce que nous voyons ailleurs. C'est presque comme si Apache essayait d'allouer équitablement les connexions pour empêcher les persistantes de mourir de faim les autres - mais ça ne ferait pas ça, n'est-ce pas?!
Je ne voudrais rien de plus que d'être dit que nous faisons quelque chose de stupide ici! S'il vous plaît, s'il vous plaît dites-moi que je suis un idiot, ou au moins myope ...
Je vous suggère de poster ceci sur serverfault.com aussi bien pour une meilleure réponse . – JoseK
Ouais, je l'ai fait. Il y avait 8 vues là-bas et même pas un commentaire, allez comprendre. –