|
Impact de la taille des objets HttpSession sur la performance des applications J2EE
La personnalisation des services sur un site de commerce
électronique passe nécessairement par la collecte de données précises sur les
besoins des clients et le suivi de leurs différentes interactions avec le site.
Intrinsèquement, le protocole http ne prend pas en charge ces deux tâches parce
qu’il est conçu pour mettre fin à la connexion courante dès que le serveur web
envoie une réponse aux différentes requêtes reçues. A vrai dire, le protocole
http a une mémoire éphémère (stateless). Après la clôture de la connexion
courante, il ne se souvient ni des clients qui ont déjà eu recours à ses
services ni des données transportées par les différentes requêtes qu’ils ont
envoyées.
Pour permettre à l’application Web de se souvenir des données des clients avec
lesquels elle a eu de récentes interactions, les développeurs ont recours au
mécanisme des sessions [157]. Dans Java celui-ci est souvent mis en œuvre par le
biais de trois artifices :
• Les champs HTML cachés : cette technique consiste à insérer des indices (tokens)
dans des champs cachés d’un formulaire HTML [158]. De cette manière
l’application reconnaît le client à chaque fois que l’indice lui est transmis
par une requête http.
• Les cookies : chaîne de caractères déposée dans un fichier sur le disque dur
du client. A moins qu’elles ne soient bloquées, les données stockées dans cette
chaîne sont transmises à l’application Web à chaque fois qu’une requête lui
parvient du même client.
• La réécriture d’URL : cette technique est souvent utilisée lorsque le client
bloque la réception des cookies. Elle consiste à ajouter un identifiant unique à
tous les liens hypertextes qui se trouvent sur la vue. A chaque fois que le
client clique sur ces liens une requête contenant l’identifiant unique est
envoyée à l’application pour lui permettre de le reconnaître.
Les artifices décrits ci-dessus font appel à des données insérées dans la vue ou
sur le disque dur du client. Ils décentralisent la gestion des sessions au
niveau de la couche de présentation. Cette décentralisation peut s’avérer fatale
pour la performance de l’application car :
• L’utilisation de la technique des champs cachés avec la méthode POST [159] ne
contingente pas la quantité de données échangée entre le client et le serveur. A
mesure que cette quantité croît le réseau s’engorge et le temps d’acheminement
des requêtes vers le serveur augmente [160].
• La réécriture d’URL augmente le temps nécessaire pour générer la vue et réduit
les possibilités de mise en cache.
• Les données véhiculées entre le client et le serveur ne sont pas réutilisées
par les différents composants de l’application [161]. Elles doivent être re-collectées
à chaque fois qu’un composant en a besoin. Il en résulte des redondances dans
l’envoi /réception des données et une mauvaise factorisation du code au niveau
des composants.
Même s’il s’appuie sur les cookies ou la réécriture d’URL, le mécanisme de
gestion de session intégré au package javax.servlet.http.HttpSession permet de
réduire de façon significative la quantité de données véhiculées entre le client
et le serveur.
Ainsi lorsque le client envoie pour la première fois une requête à
l’application, le conteneur servlet lui attribue un identifiant unique [162] qui
permet de le reconnaître à chaque nouvelle interaction. Il crée ensuite un
Hashtable [163] appelé HttpSession object où il stocke les données reçues du
client. De cette façon ces données ne sont transportées qu’une seule fois vers
l’application.
Après leur stockage dans l’objet HttpSession elles peuvent être lues ou
modifiées par d’autres servlets et JSP. Il est important de souligner que le
conteneur crée autant d’objets HttpSession qu’il y a de clients et que chaque
client ne peut accéder qu’aux données de l’objet qui lui est dédié.
Les avantages de cette technique se situent à deux niveaux :
• Le réseau est soulagé parce que l’identifiant unique est la seule donnée
transférée entre le client et le serveur.
• Les données sont lues et modifiées plus rapidement parce qu’elles sont
stockées dans la mémoire vive du serveur.
Figure 33: Gestion des sessions par le biais du mécanisme intégré à l’objet
HttpSession [164]
Pour plus de détails,
consulter cet
article
qui analyse l'impact de la taille des objets HttpSession
sur la performance des applications J2EE
Notes de bas de page
[157] Dans la plupart des cas les informations stockées dans
les sessions expirent lorsque le client ferme le navigateur, se déconnecte (log
out), se dirige vers un autre site ou encore lorsque la durée de la session est
révolue.
[158] Champs dont l’attribut TYPE est égal à HIDDEN.
[159] La méthode GET en revanche limite cette quantité à 240 caractères
[160] A en croire un article paru sur precisejava.com la performance diminuerait
de façon inversement proportionnelle à la quantité de donnée véhiculée. Pour
plus de détails voir Ravi Kalidindi and Rohini Datla , Best Practices to improve
performance in Servlets,
http://www.precisejava.com/javaperf/j2ee/Servlets.htm#Servlets106
[161] Servlets, JSP …
[162] Cet identifiant est attribué par le biais d’un cookie ou de la réécriture
d’URL
[163] Le conteneur crée un nouvel objet pour chaque session
[164] Source: inspiré d’un schéma du livre Budi Kurniawan, Java for the Web with
Servlets, JSP, and EJB, A Developer's Guide to J2EE Solutions, New Riders
Publishing, April 12, 2002, 0-7357-1195-X pages 976
|
Accueil 
Conception 
