Bonnes pratiques de développement : 1er partie – les sessions

Bonjour à tous,

Aujourd’hui, je fais un petit article sur le développement, et plus particulièrement l’utilisation des sessions.
Je pense que pour beaucoup d’entre vous qui font du développement c’est une notion bien connu, mais ça ne fait pas de mal de faire une piqûre de rappel.

La session : quézako ?

La session est une période de temps durant laquelle le client est connecté de façon unique sur un serveur.
Pour cela, très souvent, nous (les développeurs) mettons des informations liées au client dans la session du serveur afin de pouvoir savoir qui réalise l’opération.
Exemple en php :
$idUser = $_SESSION['idUser'];
Dans l’exemple ci-dessus, on récupère l’identifiant unique de l’utilisateur présent en session

Les sessions sont indispensables dans tout site actuel. Cependant, ça devient vite fourre tout.

La bonne utilisation des sessions

La session ne doit en principe stocker que les informations qui servent partout sur le site. Habituellement, il s’agit du numéro d’identifiant de l’utilisateur de la base de données. En effet, ce nombre permet de savoir qui est la personne, puisqu’il est unique (un peu comme votre numéro de sécurité sociale).
Si un site affiche sur toutes ses pages le nom de la personne, alors il peut être intéressant de le mettre en session aussi afin de ne pas faire des requêtes en base à chaque chargement de pages. Encore qu’il existe d’autres solutions que la session dans ce cas (la mise en cache par exemple).

Le problème est que très souvent des développeurs inexpérimentés se servent de la session comme un fourre tout.

    Quelques exemples véridiques de session fourre tout :

  • la liste de résultat d’une recherche mise en session. Pas les critères de la recherche, mais bien la liste de résultats. o_O
  • la liste des communes des départements
  • des formulaires entiers
  • etc
  • Les impacts d’une mauvaise utilisation

    Cette partie va plus porter sur le fonctionnement java, mais reste vrai en général.
    Le problème de mettre tout et n’importe quoi en session, c’est qu’elle est stockée en mémoire vive et reste rempli tant que l’utilisateur est connecté. S’il se déconnecte, la session se vide, mais s’il ne le fait pas (ferme son navigateur par exemple), la session reste en mémoire tant que le time out du serveur n’est pas arrivé (très souvent c’est 30min).
    Si vous n’avez qu’un utilisateur sur votre site, mettre tout en session n’est pas un problème, votre serveur tiendra la charge. Mais maintenant imaginez un site comme chronodrive. S’ils utilisent à tort la session, le serveur tombera très rapidement.
    J’ai déjà vu sur certains projets sur lesquels j’intervenais, des serveurs qui tombaient à cause de la trop grosse utilisation de la mémoire par le processus java dû à une mauvaise gestion de la session.

    Les remèdes

    Si vous en êtes au début de votre développement, préférez les requetes en base ou l’utilisation du cache pour les informations non essentielles.
    Il vaut mieux avoir une base de données bien pensée, avec des requêtes optimisées, qu’une session qui récupère la moitié de la BDD à cause des temps d’accès.

    Si vous avez déjà développé votre site et que ce dernier ne tient pas la charge, vous avez deux solutions : la première vous essayez de mettre en place un cache et vous allégez la session. La deuxième, vous n’avez qu’à tout recoder. j’exagère un peu mais j’ai déjà eu affaire à des projets où ça a été la seule solution. En effet, la session était une vrai poubelle et la BDD n’était pas optimisée. Aussi dès qu’il y avait 10 utilisateurs en simultanés sur le site, ce dernier s’effondrait.

    Pour conclure, la session est un outil très pratique, mais elle ne doit servir qu’à stocké des informations indispensables au bon fonctionnement du site. Quand ça dépasse une dizaine de variable (et encore, là je suis très généreux) c’est qu’il y a un problème dans votre site et que vous devriez le repenser (revoir son architecture, la BDD, etc).