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.