Variables de session: combien de données, c'est trop?
Je n'ai vu que des exemples de variables de session utilisées pour stocker de petites quantités de données, comme un seul identifiant utilisateur. Je me demande s'il serait plus efficace de conserver à la place des données plus fréquemment consultées dans les variables de session pour éviter d'interroger la base de données.
Par exemple, j'ai créé une classe d'utilisateurs qui rassemble des données régulièrement demandées pour cet utilisateur lors de la construction (leur identifiant, nom d'utilisateur, e-mail, mot de passe et tableaux de données spécifiques au site) et je tiens cette instance en tant que variable de session. Après la connexion initiale de l'utilisateur, la base de données doit rarement être interrogée pour obtenir des informations sur l'utilisateur car elle est déjà en mémoire.
Suis-je réellement plus efficace, ou suis-je simplement en train d'enliser le système avec l'utilisation de la mémoire?
Note latérale - Je trouve en fait plus facile de récupérer des données de la session au lieu d'avoir à me soucier d'optimiser mes requêtes et mes trucs, donc j'espère vraiment que je ne suis pas un idiot.
Premièrement, PHP ne sont pas stockées en mémoire par défaut , elles sont stockées sur le disque, donc chaque bloc/la session dans laquelle vous écrivez va occuper de l'espace disque et non de la mémoire (jusqu'à ce que vous utilisiez PHP pour lire les données de session).
Oui, vous êtes potentiellement plus efficace, mais pas si vous voulez évoluer et voici pourquoi:
Stockage de données dans des sessions
Il est parfaitement acceptable de stocker certains données dans les sessions. Théoriquement, il n'y a pas de limite (même si je n'ai jamais essayé de le casser ou même de le pousser, il suffit de passer à une solution plus efficace). Vous serez cependant limité par l'espace disque et PHP memory_limit() .
Souvent, les données stockées dans les sessions incluent des éléments tels que:
- Noms d'utilisateur
- Hashs
- Dates d'inscription
- Autres variables (identifiants/clés de groupe d'utilisateurs, etc.)
- Messages flash
- (PAS des mots de passe!)
Cependant, il y a un compromis. Si votre trafic (et votre utilisation) augmente et que vous stockez beaucoup de données dans $_SESSION, Vous commencerez très probablement à voir des problèmes, à la fois en termes d'utilisation du disque et de la mémoire.
Je ne pense pas qu'il y ait de problème avec ce que vous proposez, mais au-delà des éléments que vous avez énumérés et où les exemples ci-dessus se chevauchent, des précautions sont nécessaires.
Si vous souhaitez mettre à l'échelle (horizontalement) et conserver les sessions sur disque, vous avez des options ( sessions persistantes ou le réseau de stockage est un couple) car le disque sur un serveur ne stocke pas les mêmes sessions que un disque sur un autre serveur.
Emplacement des données de session
Vous pouvez trouver l'emplacement où PHP stocke les données de session en appelant: session_save_path()
ou sur la CLI:
php -r 'echo session_save_path(), "\n";'
Vous n'avez pas mentionné votre système d'exploitation, mais les emplacements courants des fichiers de session (sur différents types de système d'exploitation) sont:
/tmp
/var/lib/php5/
/var/lib/php/session
c:/wamp/tmp
Les sessions stockées sur le disque ont généralement des noms de fichiers qui ressemblent à ceci en utilisant ls -al:
-rw------- 1 www www 0 2013-07-09 20:12 sess_bdsdjedmvtas5njhr5530b8rq6
Il convient de noter qu'il existe souvent des processus de récupération de place qui nettoient les sessions mortes après des périodes spécifiques. Il varie selon le système d'exploitation, mais ils sont généralement présents avec diverses installations basées sur LAMP.
Autres options/approches de stockage de session
Dans votre base de données
Les données de session sont souvent stockées dans une base de données plutôt que sur un disque local et cela fonctionne bien pour les sites micro, petits et (selon la façon dont ils sont faits) moyens avec un niveau de trafic raisonnable.
Comme toute autre solution, il a ses avantages et ses inconvénients (comme être en mesure d'interdire/expulser un utilisateur en exécutant une requête plutôt que de supprimer un fichier de session de /tmp)
En mémoire
pour les sites plus grands (à trafic plus élevé) et en particulier lorsque le volume d'utilisateurs simultanés est élevé, la mémoire est plus rapide à lire/écrire pour les variables ou les données très fréquemment consultées au lieu d'ajouter une charge excessive à votre base de données. Il peut et doit toujours être écrit dans la base de données (voir mise en cache en écriture ), mais également être conservé en mémoire pour un accès efficace.
Une technique particulièrement intéressante est mise en cache mémoire. Un exemple largement utilisé de solution open-source compatible PHP est Memcached , qui peut être utilisé sur un ou plusieurs serveurs [distribués]. J'ai vu cela utilisé par les petites entreprises comme par les grandes et il suffit de regarder qui l'utilise/contribue ...
Tout dépend des ressources du serveur et des utilisateurs simultanés de votre site Web/application.
Vous pouvez faire un calcul approximatif, en estimant la mémoire de session moyenne dont chaque utilisateur aura besoin, en la multipliant par le nombre moyen de visiteurs simultanés, et en la comparant à la mémoire dont vous disposez pour PHP dans le serveur.
Ce calcul vous aidera à estimer ce qui est trop dans votre scénario, d'une manière très approximative mais utile.
EDIT: par mémoire, je veux dire RAM et/ou espace disque, selon votre configuration.
Certaines des autres réponses supposent que vous entendez utiliser sessions PHP pour mettre en cache les données. Il s'agit d'une bonne solution pour stocker des données éphémères dont vous avez besoin pour être disponible d'une demande à l'autre.
Mais je me demande si vous entendez utiliser variables définies par l'utilisateur MySQL . Vous pouvez stocker de longues chaînes de données dans ces variables, et elles occupent RAM dans la portée de votre thread de base de données sur le serveur MySQL. Mais ces variables utilisateur le font ne pas rester en mémoire après la fermeture de votre session. Ils ne sont pas un bon moyen de stocker des données d'une demande à l'autre.
La seule raison de stocker de grandes quantités de données dans des variables utilisateur est que vous devez les utiliser dans les requêtes SQL suivantes au cours de la même session db (ce qui signifie au cours de la même PHP PHP), et vous ' dans l'espoir d'éviter de transférer cette chaîne du serveur db vers votre application. Sinon, vous pourriez aussi bien récupérer le résultat et le stocker dans une variable PHP.
Une autre solution pour stocker des données éphémères consiste à utiliser memcached . Vous pouvez stocker des données directement, ou vous pouvez utiliser memcached comme magasin de sauvegarde pour votre PHP session .
Essayez de garder à l'esprit que le paradigme du Web encourage un modèle de mémoire sans état. C'est-à-dire, chargez ce dont vous avez besoin pour rendre la page, rendre la page et libérer les ressources.
Évidemment, il y a des moments pour mettre en cache les données, mais oui, le stockage des informations dans les variables de session crée plus d'utilisation de la mémoire pour votre application dans son ensemble, et CHAQUE SESSION utilisera les N octets que vous stockez.
Si vous n'avez pas de problème de performances, ne vous inquiétez pas de la mise en cache. En revanche, si vous souhaitez mettre en cache et que ce n'est que sur un seul serveur pour un petit nombre d'utilisateurs, ne vous inquiétez pas. Soyez conscient des inconvénients de l'utilisation de variables de session dans une batterie de serveurs Web (si vous en utilisez une).