«
»

Tuning de Tomcat par Mark Thomas

Ce matin, aux Rencontres Spring, Mark Thomas a parlé du tuning de Tomcat en production. J’y ai appris plusieurs choses intéressantes que je résume ici.

Saviez-vous que 80% du temps de traitement d’une requête est faite dans l’application et non dans Tomcat.

Les logs devraient être configurés :

  • De manière asynchrone :
    • Ils sont synchrones par défaut,
    • Attention à la taille des buffers qui pourraient conduire à des OutOfMemory,
    • Mettre les loggers en fallback synchrone si les buffers sont pleins ;
  • Ne pas logger tout et n’importe quoi :
    • Remonter le niveau de log au maximum (selon la politique locale),
    • Ne pas logger dans la console.

Il est possible de cacher du contenu statique :

  • Par défaut, 10Mo de contenu sont retenus pendant 5 secondes. A changer si on a de la RAM et du contenu vraiment statique ;
  • Il existe la fonctionnalité « SEND_FILE » des connecteurs NIO et APR permettant d’indiquer à l’OS d’envoyer directement le contenu statique du disque dur vers la carte réseau.

Côté JVM, Mark rappelle que trop de mémoire est néfaste pour les performances : les GC seront plus longs. Il faut donc avoir les valeurs de XMS/XMX les plus faibles possibles. Pour cela, il faut étudier les besoins de l’application et mettre les valeurs en fonction.

Pour le load-balancing et la réplication des Sessions, le frontal sait qu’une session est affectée à un noeud tout simplement par l’usage d’un cookie spécial qui est reconnu par le frontal (mod_proxy_http par exemple).

Pour configurer le FailOver, Il suffit d’une ligne de conf. Mais la conf est plus complexe pour la Prod où il faut par exemple que les noeuds découvrent les autres membres du cluster.

Faire du load balancing avec du clustering demande un minimum de 3 instances. Mark conseille de tester cette configuration en dév et non la réserver pour la prod.

Tags: ,

This entry was posted on Thursday, November 13th, 2008 at 23:15 and is filed under java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 Responses to “Tuning de Tomcat par Mark Thomas”

  1. Erwan ALLIAUME Says:
    November 14th, 2008 at 08:48

    Cette session était en effet fort intéressante !
    On n’insistera jamais assez sur sa recommandation : corriger les causes de problèmes et non les symptômes. Si la base de données rame, avant d’en rajouter une autre, revoyez votre schéma; idem pour Tomcat, avant de le ‘fine tuner’ ou de toucher aux options du garbage collector, regardez le comportement de votre application.

  2. Blog Xebia France - Revue de Presse Xebia Says:
    November 18th, 2008 at 10:58

    [...] billets : Spring dmServer, le pari fou ?, Tuning Tomcat par Thomas [...]

  3. killbulle Says:
    November 24th, 2008 at 19:18

    Salut,

    Faire du load balancing avec du clustering demande un minimum de 3 instances.

    Pourrais-tu apporter une précision a ce que mark entendais par la je n’ai malheureusement pas pu assister a la présentation…
    merci d’avance

  4. Tom Says:
    November 24th, 2008 at 22:20

    Mark Thomas n’a pas été expansif à ce sujet (ou j’ai oublié ce qu’il a dit ;-) )
    Je me demande si cela ne voulait tout simplement pas dire : 1 frontal (tomcat) et le cluster derrière.

    Je vais lui poser la question directement, je ferai un Post s’il y a matière.

    Tom

  5. Tom Says:
    November 25th, 2008 at 10:26

    J’ai contacté Mark Thomas, qui a répondu à la question :

    What did you mean by “Load balancing/clustering : use a minimum of 3 Tomcat instances” ?

    Sa réponse :

    What I meant was that if you are running a cluster then ideally you should have a minimum of three nodes. There are a couple of reasons:
    - High availability. If you have two nodes and one node is down for maintenance then you have a single point of failure during your maintenance cycles ;
    - Fail over behaviour. You want to check that when one node fails, the traffic it was handling is split between the other two nodes. You can’t do this in a two node cluster. This becomes important in larger clusters where nodes are operating closer to capacity. If all the traffic from a single node failed over to another node this node may itself fail due to the large increase in traffic.

    Mark réalise également des présentations Web, à voir sur sur http://www.springsource.com/webinars.

    Un grand merci à Mark d’avoir pris le temps de répondre.
    Si le support de SpringSource est aussi accessible et rapide, c’est un sacré argument pour prendre leur service.

    Tom

  6. killbulle Says:
    November 25th, 2008 at 10:56

    merci, beaucoups,
    je me douter d’un réponse de ce genre, mais c sympa d’avoir demander a Mark thomas
    j’ai aussi trouvé celle ci qui est vraiment bien
    http://www.springsource.com/files/u1/PerformanceTuningApacheTomcat-Part2.pdf

    Cordialement
    Marc

Leave a Reply