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.
- Vous devez vous identifier ou créer un compte pour écrire des commentaires
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.
Damien Tournoud
808
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.
Vincent
Formations Drupal pour WEBMASTERS, DESIGNERS et DÉVELOPPEURS.
drupalfrance
1772
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 ?
Damien Tournoud
808
Je te conseille également de regarder du côté du module fastpath_fscache, qui implémente une façon de faire du EARLY_CACHE (ie. un cache qui a lieu avant le chargement des sessions).
Damien Tournoud
808
Le pb est ou ?
Au niveau d’Apache qui suit pas ou alors de MySQL ?
Parce que je suis pas sur qu’un Squid soit forcement une bonne reponse, il s’agirait ptet d’un pb de dimensionnement de serveur nan ?
tostinni
1268
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é ?
Vincent
Formations Drupal pour WEBMASTERS, DESIGNERS et DÉVELOPPEURS.
drupalfrance
1772
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…
tostinni
1268
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.
Damien Tournoud
808
OK, merci beaucoup pour votre aide.
Vincent
Formations Drupal pour WEBMASTERS, DESIGNERS et DÉVELOPPEURS.
drupalfrance
1772