Question Comment optimiser les performances de Tomcat 6 SSL


Nous utilisons Tomcat 6 sur une tranche d'Ubuntu 2 Go sur slicehost.com.

L'application JSP fwiw est Open Clinica 3.1 J'ai implémenté SSL à peu près comme il se doit, comme vous pouvez le constater:   

   <Connector port="8443"  
           scheme="https"   SSLEnabled="true"
           keystorePass="XXXXX" keystoreFile="XXXXX" 
    maxKeepAliveRequests="0"
    sessionCacheSize="0" sessionTimeout="0"  compression="on"   maxThreads="500"
    clientAuth="false"  sslProtocol="TLS" />

Le problème est que l'application Java Open Clinica effectue un grand nombre de demandes HTTP pour créer une page - à l'aide des outils de développement de Chrome, je peux voir entre 70 et 80 demandes pour une page typique.

Lorsque vous ajoutez le contrôle SSL à chaque demande, la latence réseau supplémentaire tue le temps de réponse de l'application. FWIW - les utilisateurs clients sont situés en Israël, en Europe et aux États-Unis - il n’est donc pas vraiment envisageable d’exécuter un serveur local à côté des utilisateurs. Je suis conscient que, puisque slicehose est aux États-Unis - la latence du réseau vers Israël est faible, mais j'estime que, puisque les performances HTTP du serveur étaient acceptables à bonnes - nous devrions être en mesure de faire mieux.

Pour tenter de minimiser les poignées de main SSL - J'ai défini illimité sessionCacheSize et SessionTimeout, comme indiqué dans la définition du connecteur ci-dessus.

Cependant, lorsque je lance ssldump sur le côté client, je vois encore beaucoup de contacts en cours qui semblent suggérer que Tomcat ignore en fait ces paramètres.

Le serveur n'est pas stressé - avec 5 utilisateurs simultanés, il y a environ 100 Mo de mémoire disponible et peu ou pas de permutation.


6
2017-08-14 13:46


origine




Réponses:


La négociation SSL sur chaque ressource est un signe révélateur que HTTP rester en vie la fonctionnalité ne fonctionne pas.

Avec keep-alive, une liaison SSL unique est établie pour une connexion TCP, puis plusieurs ressources peuvent être demandées via cette connexion unique. Les navigateurs modernes aiment ouvrir plus d’une connexion TCP pour éviter les goulets d’étranglement sur les ressources à chargement lent. Vous verrez donc toujours plusieurs poignées de main, mais certainement moins qu’avec Keep-Alive Off.

maxKeepAliveRequests="0" Je pense que la désactivation de Keep-Alive (je ne trouve pas de documentation sur ce que fait 0; 1 désactive Keep-Alive et -1 ne définit aucune limite - je suppose que 0 est également une désactivation effective).

Si vous aviez l'intention de désactiver Keep-Alive, je vous conseillerais de reconsidérer; si vous avez l'intention de le définir en illimité, définissez cette option sur -1.


5
2017-08-14 18:01



Sur Apache HTTPd, la définition de maxKeepAliveRequests sur 0 définit un nombre illimité de keepalives, mais je conviens avec vous que, sur tomcat, sa définition sur 0 peut effectivement les désactiver. - mahnsc
@mahnc Bon appel. tomcat.apache.org/tomcat-6.0-doc/config/http.htmlétait spécifique sur la définition de maxKeepAliveRequests à -1 pour un nombre illimité. Mon mal pour la confusion avec les paramètres Apache. La documentation n'indique pas quelle valeur 0 signifie, mais ssldump semble indiquer qu'il l'éteint. - Danny Lieberman
@ Danny Est-il réglé à -1 pour résoudre la poignée de main excessive? - Shane Madden♦
@ mahnc Oui. Je surveille le serveur aujourd'hui et le réglage sur -1 fait l'affaire. Les utilisateurs signalent également une expérience utilisateur améliorée. Merci pour f / u. En regardant la documentation de Tomcat6, je dirais que cela nécessite un travail sérieux ;-) - Danny Lieberman
@ Danny Great - si le problème est résolu, continuez et cochez la case en haut à gauche de la réponse pour l'accepter. - Shane Madden♦


Je suggérerais d'utiliser un proxy inverse Apache avec le connecteur AJP à l'avant. Placez le SSL dans Apache et connectez-vous à Tomcat en texte clair via un lien privé (par exemple, localhost).

Utilisez Apache pour ses atouts (serveur Web offrant de nombreuses options de fantaisie) et Tomcat pour ses atouts (applications Java).


0
2017-08-14 21:28



- Je suis d'accord en général, mais nous utilisons actuellement un seul serveur exécutant Tomcat 6. Logiquement, l'ajout d'une autre couche de proxy sur le même serveur n'a aucun avantage, même si nous supposons qu'Apache avec Open SSL est plus rapide que Tomcat avec Java. SSL - le goulot d'étranglement n'est pas le serveur mais la latence du réseau provoquée par le nombre de liaisons SSL établies par les navigateurs clients distants. Il me semble que, étant donné que les poignées de main sont la cause première du problème, nous avons besoin d’un moyen efficace de mettre en cache les demandes du client SSL et non de remettre en contact chaque demande http. - Danny Lieberman
Si nous supposons qu'apache / openssl fonctionne mieux que tomcat / jsse (et que cela ne peut être vrai que par fortes charges), nous avons l'option de devenir natif avec tomcat afin que nous puissions utiliser openssl à cet endroit. Cependant, changer le paramètre MaxKeepAliveRequest de 0 à quelque chose comme 500 (valeur par défaut d'Apache) semble être un bon début. Dites-nous comment cela a fonctionné? - mahnsc
@mahnc J'ai défini MaxKeepAliveRequest = "- 1" (illimité) car la machine n'est pas sollicitée en ressources de processeur ou de mémoire et, étant donné que l'application Web effectue 70 à 80 requêtes http par page, nous aurons besoin d'une limite de maintien en vie de toute façon. à mesure que nous augmentons le nombre d’utilisateurs sur le système. Certes, je devrai rester attentif aux statistiques du système. - Danny Lieberman


Garder en vie est évidemment le plus gros gain que vous aurez, mais si vous devez toujours réduire le temps de latence, vous devez vérifier que vous utilisez le connecteur natif APR.

http://tomcat.apache.org/tomcat-6.0-doc/config/http.html#Connector Comparaison


0
2017-08-16 08:14