Question Memcache + Réglage de session PHP: Comment Memcache expire-t-il les clés?


J'ai fait des recherches à ce sujet et je n'ai pas trouvé de réponse définitive.

Nous avons une application Web qui utilise le gestionnaire de session PHP + Memcache.

J'ai plusieurs questions, toutes interdépendantes, mais mon problème est finalement: "Pourquoi les sessions PHP n'expirent-elles apparemment pas alors que nous pensons qu'elles devraient l'être?" En d'autres termes, l'utilisateur final doit être déconnecté de l'application au bout d'un délai déterminé, mais ne l'est pas.

Voici les points, aidez-moi s'il vous plaît à les connecter et dites-moi où je me trompe:

  • D'après ce que je comprends, Memcache expire les clés en fonction de la durée définie, en secondes (ou de l'horodatage unix pour les valeurs plus grandes).
  • L’expiration est paresseuse - c’est-à-dire que rien n’est supprimé à l’avance
  • Le gestionnaire de session memecache PHP utilise sessions.gc_max_lifetime pour définir l'expiration de la clé memcache. idk, peut-être que non?
  • Memcache devrait, en servant une clé demandée et en voyant qu'elle est expirée, pas la servir (et ensuite peut-être aussi la supprimer?). Mais au moins pas le servir.
  • Le fait de ne pas le servir devrait, pour PHP, équivaloir à une session supprimée et à l’utilisateur déconnecté.

Les utilisateurs ne sont pas déconnectés.

Comment puis-je même déboguer cela? Memcache n'est pas vraiment transparent.

Le cas d'exemple qui n'a pas fonctionné est un site avec un délai de session défini sur deux heures. Un exemple d'utilisateur utilisait le site pour la dernière fois la nuit, puis 8 à 10 heures plus tard, revenait sur le site et était toujours connecté.


7
2017-10-24 16:20


origine


peut-être le bug suivant: bugs.debian.org/cgi-bin/bugreport.cgi?bug=620258 - c33s
Le problème avec la gestion de session basée sur memcache est que si vous manquez d'espace mémoire, vos sessions vont commencer à disparaître ... et vos utilisateurs se fâcher. - Jauzsika


Réponses:


Nous avons également rencontré ce problème, mais nous avons réussi à creuser et à comprendre exactement ce qui se passe. Le problème rencontré est que memcache (avec une allocation de mémoire raisonnablement grande sur plusieurs serveurs) a commencé à expulser le contenu. Cela n'est pas souhaitable, car cela peut avoir un impact négatif sur les visiteurs actuels du site.

En surveillant le trafic réseau, nous avons vu les messages de PHP à Memcache comme suit:

set memc.sess.key.abcdabcdabcdabcdabcdabcd 0 0 1823 données ...

C'est le deuxième zéro qui cause les problèmes - cela détermine la durée pendant laquelle memcache met l'élément en mémoire cache. En le réglant à zéro, memcache n'expire jamais cet élément. Dans votre cas, cela signifiait que les utilisateurs pouvaient revenir des heures plus tard et continuer à accéder à votre site. Dans notre cas, memcache se remplissait et provoquait l'expulsion des données souhaitées.

J'ai creusé plus loin, et cela se résume à l'extension PHP memcached. Depuis la version 1.0.2 (que nous utilisons), ce code se lit comme suit:

sess_lifetime = zend_ini_long(ZEND_STRL("session.gc_maxlifetime"), 0);
if (sess_lifetime > 0) {
    expiration = time(NULL) + sess_lifetime;
} else {
    expiration = 0;
}

Dans cet extrait, c'est ZEND_STRL("session.gc_maxlifetime") qui ne retourne pas la valeur attendue. Cela a été rapporté comme un bug de PHP, et un correctif à la bibliothèque memcached est décrit à https://bugs.php.net/bug.php?id=59641.

J'ai déployé ce correctif, examiné le trafic réseau et constaté qu'il définissait l'heure d'expiration comme prévu.


10
2018-01-16 17:45



Comment votre PHP est-il déployé? Personnalisé compilé à partir de la source? Fichiers binaires de distribution Linux + mises à jour de distribution? Etc .. Sinon, merci pour le tuyau, cela semble très prometteur! - JDS