Le cache de Drupal et les sessions

Information importante

En raison d'un grand nombre d'inscriptions de spammers sur notre site, polluant sans relache notre forum, nous suspendons la création de compte via le formulaire de "sign up".

Il est néanmoins toujours possible de devenir adhérent•e en faisant la demande sur cette page, rubrique "Inscription" : https://www.drupal.fr/contact


De plus, le forum est désormais "interdit en écriture". Il n'est plus autorisé d'y écrire un sujet/billet/commentaire.

Pour contacter la communauté, merci de rejoindre le slack "drupalfrance".

Si vous voulez contacter le bureau de l'association, utilisez le formulaire disponible ici, ou envoyez-nous un DM sur twitter.

Bonjour,

Mon hébergeur vient de me signaler un problème de mise en cache des pages avec Drupal :

Apparemment, Drupal génère un ID de session pour chaque utilisateur surfant sur le site, qu'il soit anonyme ou identifié. Or, la présence de cet ID de session empêche la mise en cache des pages demandées par cet utilisateur. L'idéal serait donc que seuls les utilisateurs identifiés aient une session, et que les utilisateurs anonymes n'en aient pas.

Lorsqu'on développe une application PHP soi-même, il s'agit de ne pas faire appel à session_start() pour les utilisateurs anonymes. Mais avec Drupal, comment faire ? Certains d'entre vous ont-ils déjà rencontré ce problème ?

Dans ce cas précis, le site a beaucoup de connexions et finit par "tomber" au bout d'un moment, car incapable de gérer la mise en cache des pages.

Merci.

Je ne comprends pas bien ton problème Vincent. Cette "mise en cache des pages" est faite en dehors de Drupal (par exemple sur un cache Squid), j'imagine? Parce que sinon, je ne vois pas pourquoi Drupal (par son cache interne) ne serait pas capable de mettre en cache les pages vue par les utilisateurs anonymes.

Salut Damien,

En effet, la mise en cache est faite en dehors de Drupal. Mais un des critères retenus pour savoir si une page peut être mise en cache ou pas (par la solution que l'hébergeur utilise - je ne sais pas laquelle) est la présence d'un ID de session dans l'entête de la page. Comme toutes les pages Drupal possèdent un ID de session, la solution est incapable de les mettre en cache.

Bon, c'est donc le cookie de session qui gène la mise en cache.

Je ne pense pas que l'on puisse faire quoique ce soit contre ca, pour un simple problème de poule et d'oeuf : si l'utilisateur est identifié, il faut appeler session_start() pour charger ses variables de session, mais réciproquement, il faut charger les variables de session pour savoir si l'utilisateur est identifié.

Non?

Merci pour vos retours.

@tostinni

Je ne suis pas expert en cache, et je ne fais que rapporter les propos de l'hébergeur. D'après ce que j'ai compris, il utilise une solution de cache sur le serveur qui est incapable de cacher les requêtes qui ont un ID de session associé. Le problème ne vient donc ni d'Apache ni de MySQL, mais de la solution de cache (cela dit, j'imagine que la plupart des solutions cache fonctionne de la même manière).

@damz

Si j'ai bien suivi, tu dis qu'on doit utiliser session_start() dans tous les cas (que les utilisateurs soient identifiés ou pas), et que donc, par conception, chaque requête a nécessairement un ID de session associé ?

Ce qui est sur c'est que Drupal gere son propre cache pour les utilisateurs anonymes mais cela se fait au niveau de la BDD et justement ce type de comportement empeche de mettre en cache via squid ce genre les pages vues par les anonymes.

Une fois que les pages sont mises en cache au niveau de Drupal, il suffit alors de tres tres peu de requetes pour regenerer la page, c'est donc pour cela que je me disais que ptet que ton serveur etait pas assez puissant par rapport au traffic que tu attends sur ce site...

Certes le modules dont parle Damz pourrait aider, mais je pense que c'est pas forcement une solution super simple a mettre en oeuvre...

Je pense qu'il faudrait plus se concentrer sur ce que genere ton site qd un anonyme est connecte, combiens de requetes, le cache est-il utilise a fond etc...
Et ensuite mettre ptet un autre serveur apache (une autre machine) pour tenir la charge si t'as reelement du trafic. Sauf qu'il serait pas mal que ton hebergeur te dise ou est le goulot d'etranglement...

Dans l'architecture actuelle, oui.

On pourrait faire autrement, par exemple en exécutant le session_start() seulement lorsque le cookie de session est présent. Dans ce cas, il faudrait s'assurer que les sessions sont bien démarrées à la demande (lorsque $_SESSION est utilisé).

Malheureusement, le Form API utilise $_SESSION lorsque n'importe quel formulaire est affiché, pour des raisons de sécurité. Du coup, afficher ne serait-ce que le formulaire de recherche démarrerait les sessions. L'intérêt de mettre en oeuvre ce système de "sessions à la demande" me semble donc limité.

Au fait, une fois la session démarrée pour un utilisateur donné, il est impossible de la fermer. Toutes les pages suivantes qui seraient affichées seront donc impactées.

Un peu tard mais pour les autres...

Tu peux désactiver le cache pour les utilisateurs anonymes (Performances)

Si tu veux empecher toute session d'être faite pour les utilisateurs anonymes, il te suffit de supprimer dans la base de données, table users la ligne uid = 0
Dès lors, plus de sessions possible pour les anonymes