Quel est le stockage de session le plus fiable en PHP: Memcache, base de données ou fichiers? [fermé]


10

Quelle est la manière la meilleure et la plus sûre de gérer les sessions PHP. Est le meilleur moyen de stocker des sessions dans:

  1. Base de données (plus fiable, mais goulot d'étranglement élevé, vitesse lente, pas bon pour les sites Web à forte utilisation de base de données)?

  2. Memcache (super rapide, mais distribué plus de problèmes de sécurité, chances de perdre des données lorsque le serveur redémarre et chances de perdre des données lorsque le cache est plein)?

  3. Fichiers (option par défaut, je suppose lent car il lit et écrit à partir des E / S de fichiers, moins de sécurité, etc.).

Quelle méthode est la meilleure? Quels sont les problèmes et les bonnes choses de chacune de ces approches?


2
Je pense que vous devez spécifier si vous utilisez une seule machine ou si l'application est distribuée, car cela influencera fortement les réponses.
Arseni Mourzenko

1
@haylem c'est l'endroit le plus approprié pour poser cette question, ce n'est pas une question de programmation son problème conceptuel de programmation,
user1179459

3
C'est vraiment une mauvaise question car «le meilleur» dépend de votre situation spécifique. Le «meilleur» pour Facebook n'est probablement pas le même «meilleur» pour votre page d'accueil personnelle.
GrandmasterB

1
@GrandmasterB je sais que c'est pourquoi j'ai clairement demandé "Quels sont les problèmes et les bonnes choses de chacune de ces approches?" pour savoir lequel est le meilleur pour moi.
user1179459

Réponses:


6

Le mieux est de stocker sur Memcached car nous pouvons facilement résoudre les autres problèmes (taille du cache, sécurité, etc.)

facebook est le premier consommateur de memcached. Veuillez lire si vous êtes intéressé: http://www.facebook.com/note.php?note_id=39391378919

Comment résoudre les autres problèmes?


4

Pour la grande majorité des applications quotidiennes, la conservation des sessions dans les bases de données est très bien. Le volume et le niveau de concurrence qu'un serveur SQL peut gérer sera plus que suffisant. La clé est de garder chaque entrée de petite taille et de purger les lignes inutiles avec régularité. Et une indexation correcte, bien sûr.

Le système de fichiers - je n'ai jamais vu la nécessité de le faire. Je préfère la simplicité de la gestion des lignes dans les tableaux plutôt que des milliers de petits fichiers. De plus, vous ne pouvez pas interroger les fichiers si vous souhaitez creuser dans les statistiques de session.

Gardez à l'esprit, avec PHP, ses gestionnaires de session faciles à échanger. Vous pouvez donc commencer avec un format de stockage et migrer vers un autre sans trop de tracas.


4

Qu'en est-il de l'utilisation du moteur de stockage MEMORY dans MySQL?

Il n'est pas aussi rapide que Memcache mais a l'avantage que vous pouvez utiliser du SQL simple, et vous pouvez également utiliser le moteur de stockage normal lorsqu'il ne sera pas nécessaire et basculer sur MEMORY lorsque le nombre d'utilisateurs / demandes augmente.

Je l'utilise pour stocker de grandes quantités de données statistiques dans une application Web qui change fréquemment, de sorte qu'elle n'est pas utilisée pour gérer les sessions, mais je pense qu'elle devrait être bien adaptée à cette fin.


3

Ce billet de blog montre les résultats d'une comparaison des performances de différents moteurs de stockage de session avec Magento et ils semblent avoir conclu que jusqu'à environ 75 utilisateurs simultanés, il n'y a pas vraiment de différence de performances entre eux.

Je pense qu'à ces niveaux (ils ont eu environ 5 transactions par seconde, ce qui représenterait environ 430 k hits sur une période de 12 heures), le surcoût dans tout le reste domine les performances que vous voyez puisque file / DB / Memcache / Redis se débrouillera tous avec plaisir. le trafic sans casser une sueur s'il est utilisé correctement.

Cela laisse d'autres facteurs tels que l'évolutivité, la fiabilité et la sécurité.

J'aimerais d'abord dire que tout ce qui compromet le stockage de vos fichiers compromettra probablement tout le reste, car un attaquant peut alors simplement modifier le code de votre application ou, à tout le moins, découvrir les clés et les protocoles / identifiants d'accès au stockage, même s'ils sont en lecture seule. accès. Le stockage de fichiers fonctionnera bien pour un site à faible volume, est facile à configurer et à raisonner. Autant que vous dites que vous frappez le disque, une lecture de base de données frappera également le disque et si la base de données peut le mettre en cache, votre système d'exploitation aura également probablement mis en cache le fichier de session. En outre, son seul fichier est lu et votre système de fichiers est brillant pour y accéder si vous connaissez déjà son nom. Si vous utilisez PHP, savez-vous combien de fichiers le système doit lire pour servir votre application? L'inconvénient est que vous pouvez

Memcache est relativement rapide et si vous envisagez des solutions de classe Memcache plus largement (Redis, etc.), il y en a qui promet même la persistance avec des lectures en mémoire pour la vitesse afin que vous tiriez le meilleur parti des deux mondes. Ils sont également relativement simples à raisonner et la nature des valeurs-clés des sessions est exactement ce pour quoi elles ont été conçues. Savez-vous combien vous auriez à consacrer à une session pour en remplir un? De toute façon, toutes vos options vous obligeront à faire des compromis si vous atteignez leur capacité. Les disques se remplissent de fichiers (nombre et facteur de taille ici), les magasins de cache se remplissent de capacité et les bases de données ont un nombre limité de lignes et les mêmes limites de capacité de disque que l'approche des fichiers. En outre, ces systèmes ne sont distribués que si vous les exécutez de manière distribuée. La plupart fonctionnent très bien avec une configuration de serveur unique. Si vous les distribuez, vous disposez probablement déjà de serveurs Web / serveurs de bases de données, etc., de sorte que vos problèmes de système distribué n'apparaîtront certainement pas dans votre choix de stockage de session. Cependant, lorsque vous voulez 10 fois plus de trafic / capacité, etc., y arriver est beaucoup plus naturel qu'avec le système de stockage de fichiers. Certains magasins de clés / valeurs vous permettront également d'effectuer des analyses simples des données de session relativement facilement, mais la plupart ne vous permettront pas de savoir ce que SQL peut faire.

Je ne sais pas pourquoi vous proposez que la base de données soit plus fiable que les autres options, mais je reçois l'attrait de la base de données car votre application PHP l'utilise probablement déjà. Cela signifie que vous n'ajoutez pas une autre dépendance de serveur et que vous pouvez probablement réutiliser la même connexion que vous utilisez pour récupérer les données de session pour obtenir les données utilisateur afin que vous n'ayez pas à en établir une pour les données, une pour Memcache, etc. Si vous indexez le table bien, il fonctionnera également assez rapidement et fournit une sémantique assez simple que vous connaissez déjà pour récolter d'anciennes sessions ou même analyser les données de session (je ne sais pas pourquoi vous le souhaitez et si vous ne l'êtes pas non plus, cela ne fonctionne probablement pas) t tant d'importance). La mise à l'échelle à des échelles massives n'est pas aussi triviale qu'avec quelque chose comme Redis,

Je pense que ce choix n'est pas si important au début. Chaque approche présente des défis, des avantages et des choses auxquelles vous devez penser. De manière générale, vous pouvez probablement vous en sortir en utilisant simplement les paramètres par défaut de PHP / quel que soit le framework que vous utilisez ou même simplement la chose la plus simple pour commencer. Si le choix s'avère mauvais par la suite, votre analyse des performances vous le dira et vous serez armé des données dont vous avez besoin pour faire les choix appropriés compte tenu de la nature spécifique du trafic que vous obtenez. À l'avant, tout ce que vous pouvez raisonnablement avoir, c'est de la spéculation générale.


0

Cela dépend de vos besoins.

Il existe certaines différences entre les fichiers et le stockage de la base de données. Voir cette question .

Cependant, vous pouvez faire ce qui est fait dans Rails 3 par défaut, et utiliser uniquement des cookies cryptés pour votre session. Ainsi, vous cryptez toutes les valeurs de manière à ce que vous seul puissiez les décrypter plus tard (par exemple, les clés privées / publiques), et vous laissez le client faire le suivi de l'état pour vous.

D'une part, cela vous limite à 4 Ko, ce qui est généralement suffisant (car vous voulez généralement stocker des identifiants, pas des objets entiers), mais l'avantage vraiment agréable que vous obtenez est que vous n'avez pas à vous soucier du nettoyage de la session. Vous laissez cela au client, où il devrait être.


2
Sauf si vous avez séparé vos ressources statiques pour être en dehors de votre chemin de cookie, les cookies sont une taxe fixe que vous devez payer à chaque demande.
Joeri Sebrechts

jQuery et Bootstrap sont environ 150 Ko combinés, et c'est sans autres bibliothèques. Le cookie maximum est de 4 Ko et généralement inférieur à 1 Ko. À moins que le PO ne pose des questions sur des circonstances extrêmes - qui se soucie de ce type de taxation?
Yam Marcovic

@YamMarcovic il y a peu de problèmes 1) les cookies vont aussi au serveur (les utilisateurs ont généralement un téléchargement plus rapide puis un téléchargement) en remontant
Miro Svrtan

@MiroSvrtan Si vous faites envoyer à vos utilisateurs des centaines de demandes par page (où cela est-il arrivé?), L'optimisation n'est clairement pas un problème pour vous.
Yam Marcovic

J'avais un client dont le site faisait ~ 170 requêtes HTTP pour charger la page d'accueil avant de me consulter pour des optimisations de vitesse, alors ça arrive, croyez-moi. En fait, les clés privées / publiques sont un concept issu de la cryptographie asymétrique, qui ne serait généralement pas appliqué dans ce scénario où il équivaut à un chiffrement symétrique, mais plus complexe à mettre en œuvre. De plus, la plupart des implémentations de stockage de session reposent sur certains cookies gérés par le client, donc l'avantage décrit dans le dernier paragraphe de la réponse s'applique à tous.
jeteon

0

Pour ma situation particulière, je peux vous dire que les sessions dans une base de données sont la cause numéro un de nos blocages de serveur par une bonne marge. notre table de sessions est corrompue assez fréquemment pour que nous ayons pris le temps de la tronquer de manière préventive.

memcache semble attrayant, mais nous avons trop de processus qui effacent tout le memcache, donc les sessions utilisateur seraient interrompues trop fréquemment. et les anciennes sessions seraient effacées à mesure que la mémoire devenait pleine ... donc plus de connexions permanentes.

Nous allons bientôt essayer les sessions basées sur des fichiers par défaut.

Si vous vous inquiétez de la sécurité de vos données de session, vous ne devez pas mettre ces données dans la session - et ne pas faire confiance à la session - valider l'utilisateur à chaque demande.


0

Vous pouvez essayer d'enregistrer votre session sur Redis . Redis est rapide comme Memcached mais dispose également de plusieurs options de persistance des données. De plus, divers clients PHP sont pris en charge.

En outre, vous pouvez essayer des services tiers tels que le cloud Memcached qui possède des capacités intégrées de moteur de réplication et de stockage

Divulgation, je suis cofondateur et directeur technique de Garantia Data.


2
Merci pour la divulgation! Assurez-vous que vous participez à ce site au-delà des messages où vous pouvez mentionner vos propres produits, nous voulons que vous contribuez en tant que personne, pas votre entreprise.
Martijn Pieters
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.