Submitted by drupalfrance on
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
Permalien Soumis par Damien Tournoud le 14 Mai, 2007 - 14:53
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
Permalien Soumis par drupalfrance le 14 Mai, 2007 - 15:13
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
Permalien Soumis par Damien Tournoud le 14 Mai, 2007 - 15:22
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?
Je te conseille également
Permalien Soumis par Damien Tournoud le 14 Mai, 2007 - 16:07
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).
Le pb est ou ? Au niveau
Permalien Soumis par tostinni le 14 Mai, 2007 - 16:50
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 ?
Merci pour vos
Permalien Soumis par drupalfrance le 14 Mai, 2007 - 16:57
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
Permalien Soumis par tostinni le 14 Mai, 2007 - 17:21
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
Permalien Soumis par Damien Tournoud le 14 Mai, 2007 - 17:29
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.
OK, merci beaucoup pour
Permalien Soumis par drupalfrance le 14 Mai, 2007 - 18:21
OK, merci beaucoup pour votre aide.
Un peu tard mais pour les
Permalien Soumis par reign85 le 19 Août, 2013 - 09:55
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