Discussion :

[atomejoule]

Bonjour,

Y a t-il moyen pour que Tomcat ne crée pas automatiquement une session ?
Il y a possibilité dans la servlet de faire un "invalidate" () mais je voudrais le faire au niveau de la configuration

Merci d'avance pour les réponses

JLZ

[julien.dubois]

Ca me parait difficile à faire vu que la gestion des sessions est une obligation de la spec.

2 solutions à mon avis :
- Mettre <%@ page session="false"> pour chacune de tes JSPs
- Reduire le temps de session à 1 minute dans ton web.xml

Par curiosité, pourquoi est-ce que tu veux empêcher Tomcat de créer des sessions? Si c'est pour la perf je ne crois pas que tu gagneras grand chose.

[atomejoule]

En effet, c'est indirectement pour une question de performances, je m'explique:
nous avons à faire à une application (parmi d'autres) qui n'a pas besoin de sessions or il y a environ 40000 connexions en pic de charge ce qui implique autant de ressources (inutiles) créées au niveau du serveur.

Merci

[julien.dubois]

Les sessions doivent avoir un impact vraiment mineur en termes de perf, je ne suis pas certain que ce soit là qu'il faille chercher à gagner quelque chose.
Il y a pas mal de guides pour optimiser Tomcat, par exemple voici une présentation qui propose les principaux points intéressants :
http://us.apachecon.com/us2007/downl...g_20071015.ppt
Bonne lecture!

[atomejoule]

Merci pour le document

Je voulais juste te signaler que ton idée de passage de time-out (web.xml) à 1 minute est bonne; nous l'avions déjà adoptée (5 minutes au lieu de 1) et cela avait grandement joué sur les performances --> c'est ce qui nous a amené à creuser un peu plus de ce côté là, c'est à dire la suppression pure et simple de la session voire sa non-création, d'où ma question

A+
JLZ

[julien.dubois]

Merci pour ta réponse : cela m'intéresse de savoir que cela peut impacter les performances, je ne m'y attendais pas du tout. Si tu peux donner plus d'infos...
Dans ce cas, est-ce que tu as utilisé mon autre solution (dans les JSPs), et as-tu vu une amélioration?
Sinon, l'autre solution serait de patcher cette partie de Tomcat - ce n'est pas forcément si difficile à faire que ça en a l'air. J'ai déjà entendu parler de gens qui l'avaient patché pour remplacer le nom "jessionid" pour des raisons de sécurité (comme ça on ne sait pas que vous êtes sur un serveur JEE).

[djsnipe]

J'ai trouvé une page intéressante de ce point de vue dans la doc Tomcat : http://tomcat.apache.org/tomcat-6.0-...g/manager.html
Il est possible de redéfinir le "manager" qui s'occupe de gérer les sessions, et donc de les créer. Par contre c'est assez peu documenté, il faut creuser un peu le sujet, car quand je regarde l'implémentation par défaut (http://tomcat.apache.org/tomcat-6.0-...rdManager.html il y a un héritage, et un beau paquet d'interfaces implémentées.

Mais comme julien, je suis assez curieux des résultats. Au final, il y a quoi ? Créer quelques objets temporaires, les affecter à la request en cours et les purger ensuite. C'est à mettre en regard du coût des IO vers une base de données par exemple. Mon sentiment (et je le partage) c'est que ça n'aura aucun impact notable. Si tu as un problème de perf, il faut ajouter des sondes avec un bon debugger, et chercher les gros consommateurs puis les optimiser. Là, il me semble que c'est une piste non vérifiée, mais je peux me tromper

[julien.dubois]

Très franchement je n'y crois pas trop non plus... 100% d'accord avec djsnipe. Ceci dit la classe donnée par djsnipe donne un autre élément de réponse : les id de session doivent être des nombres aléatoires, afin de garantir la sécurité des sessions (sinon quelqu'un pourrait deviner votre ID de session et donc vous la voler). Ce calcul est probablement un peu coûteux en temps processeur, donc il s'agit effectivement de faire plus que créer quelques objets temporaires.
atomejoule, tu peux regarder le nombre de sessions ouvertes dans ton application pendant un pic de charge? Tu peux le voir dans l'application "manager" de Tomcat.

[atomejoule]

Bonjour à vous,

en effet, je me suis très mal expliqué ...
Il est clair que le problème de performances n'est pas directement lié au tracking de sessions que Tomcat gère.
J'avais omis que ces pbs de perfs. ont pour conséquence un nombre considérable (~ 20000 et 30000) de sessions en erreur. Le simple fait d'avoir abaissé à 5mn <session-timeout>, le nombre de sessions en erreur est passé à 5000: je vous l'accorde, les pbs de perfs sont ailleurs. Ceci dit dit, on voudrait totalement éliminer ce suivi de sessions mais comme c'est en lourde production (24h/24h) on ne prend pas le risque d'abaisser encore ce time-out car on ne sait pas quels seront les effets de bord.
Questions:
1) Pour voir les sessions actives dans Tomcat on passe bien par:
Tomcat Manager --> Etat du serveur --> Etat complet du serveur --> on pointe sur la webapp voulue (on visualise les infos. Active Sessions etc..) ?
2) Sous webapps\manager, il y a 2 jsp sessionDetail et sessionList, comment faire pour arriver à ces 2 jsp via la console admin Tomcat ? car elles renvoient précisément les infos. des sessions

Merci

JLZ

[djsnipe]

Juste pour info, ça veut dire quoi des sessions en erreur ?

[julien.dubois]

Pour voir les sessions actives il faut se connecter sur l'application manager : il y a alors la liste des applications dans un tableau, avec le nombre des sessions ouvertes pour chacune d'entre elles.
Au fait, je suis sous Tomcat 6.0.16, quelle version est-ce que tu utilises?
Vu ton nombre de connexions, l'OS et la JVM sont également importants, est-ce que tu peux également nous donner ces infos?

[atomejoule]

Versions
Tomcat 6.0.14
JVM Sun 1.4.2_14

A propos des "sessions en erreur" ---> dans les logs, il y avait énormément de requêtes GET/CSF undefined.. erreur 404. Ce volume d'erreurs a été ramené à 5000 au lieu des 25000 habituels ! il est vrai qu'en diminuant la latence des sessions sur le serveur, potentiellement on diminuait les sessions en anomalie. Vous avez entièrement raison sur le fait que ça ne joue pas sur les perfs. Pour l'amélioration de celles-ci il y a eu d'autres axes de recherches: GC en mode SingleCon, paramétrage judicieux du switch frontal, JVM taillée confortablement etc ...
Concernant les sessions Tomcat on recherche plus une cohérence fonctionnelle qu'une amélioration de perfs, en effet comme je vous l'ai signalé au départ, l'application n'a pas besoin de sessions donc autant les supprimer dans Tomcat. A ce propos, j'ai été voir votre URL sur le source de StandardManager.
Question:
selon vous, est-ce qu'il serait "raisonnable" de laisser à vide la méthode "createSession" et reconstruire Tomcat spécifiquement pour cette application.
Code:

public Session createSession(String sessionId) {

if ((maxActiveSessions >= 0) &&
(sessions.size() >= maxActiveSessions)) {
rejectedSessions++;
throw new IllegalStateException
(sm.getString("standardManager.createSession.ise"));
}

return (super.createSession(sessionId));

}

Par ailleurs, j'ai essayé chez moi (pas chez mon client !), la mise à zéro du time-out de session dans conf\web.xml --> apparemment ça a l'air de fonctionner: dans le manager de tomcat le 'clic' sur le nombre de sessions ne fait plus apparaître le tableau de bord des sessions, ce qui est bon signe. Ceci dit ça ne me satisfait pas complètement car j'imagine que Tomcat crée la session et la supprime dans la foulée mais peut-être je me trompe
Y a t-il un moyen de vérifier ceci ? (debug, log, autre ...)

Merci pour votre patience

JLZ

[atomejoule]

la JVM --> Sun 1.5.0_12

[djsnipe]

A propos des "sessions en erreur" ---> dans les logs, il y avait énormément de requêtes GET/CSF undefined.. erreur 404. Ce volume d'erreurs a été ramené à 5000 au lieu des 25000 habituels !

C'est bien ça que je ne comprend pas. Si les sessions ne sont pas utilisées par l'application, en quoi leur suppression change les accès vers des URL inexistantes (les erreurs 404) ?

Question:
selon vous, est-ce qu'il serait "raisonnable" de laisser à vide la méthode "createSession" et reconstruire Tomcat spécifiquement pour cette application.

Ce n'est pas reconstruire Tomcat, c'est utiliser une implémentation différente de la gestion de session pour cette application. Est-ce raisonnable de laisser la méthode vide ? Tu risques des NullPointerException si jamais d'autres couches font des vérifications. Mais c'est à vérifier. Une coquille vide serait peut être préférable.

Ceci dit ça ne me satisfait pas complètement car j'imagine que Tomcat crée la session et la supprime dans la foulée mais peut-être je me trompe
Y a t-il un moyen de vérifier ceci ? (debug, log, autre ...)

Je pense que tu supposes bien, sucharge le StandardManager en ajoutant une log dans la méthode createSession pour le vérifier.

[julien.dubois]

- Déjà je te conseillerai de passer en JDK 1.6 et bien regarder toutes les nouvelles options de paramétrage du GC.
- Ensuite tu n'as pas répondu sur l'OS... Avec autant de connexions il y a des OS qui vont clairement avoir des problèmes
- Enfin, je suis d'accord avec djsnipe : fais une nouvelle implémentation de session, que tu configures dans Tomcat et que tu ajoutes dans les lib de Tomcat. Aucun souci là dessus.

Sinon, dans ton dernier email tu parlais d'un switch frontal, j'ai donc un doute : est-ce que tu as utilisé les "sticky sessions"? Sinon ça risque effectivement de faire n'importe quoi et de créer plein de sessions pour rien (à chaque nouvelle requête tu as une chance sur n de tomber sur le bon Tomcat, et sinon tu vas recréer une nouvelle session. C'est donc (1-1/n)xle nombre de requêtes par client).

[djsnipe]

Sinon, dans ton dernier email tu parlais d'un switch frontal, j'ai donc un doute : est-ce que tu as utilisé les "sticky sessions"? Sinon ça risque effectivement de faire n'importe quoi et de créer plein de sessions pour rien (à chaque nouvelle requête tu as une chance sur n de tomber sur le bon Tomcat, et sinon tu vas recréer une nouvelle session. C'est donc (1-1/n)xle nombre de requêtes par client).

Switch ou répartiteur ?

[atomejoule]

Bonjour,

OS=Red Hat Enterprise 4

le contexte me paraît évident au point que j'en oublie quelques détails ...
au niveau du switch, tout est OK. Cet équipement sert à faire du load-balancing (pas d'apache, mod_jk ...)
On s'est aperçu que le fait de maintenir des sessions --> ressources mémoire (tout de même importantes) qui sont éligibles pour le GC. Côté soft avec un GC en SingleCon et côté switch avec un "hash balancing" ça se comporte bien mais ce n'est pas optimal (certains serveurs sont plus chargé que d'autres).
Donc pour éliminer totalement cette "démangeaison", on veut supprimer carrément les sessions.
Je vais tester votre solution:
Coquille vide pour createSession dans org. apache.....StandardManager.java

A+
JLZ