Système de cache d'objets avec MySql ou Session ?

Bonjour à tous,

Je travail sur un nouveau moteur de site et j'aimerais le doter d'un système de cache d'objets. Genre fichiers dictionnaires, config des modules et actions, statistiques. Et ce dans le but d'économiser des accès disques ou DB.

J'ai 2 pistes et j'aimerais avoir votre avis:

1. Créer une session partagée : Je ne sais pas trop comment le faire mais je suppose que je peux crée une session avec un id définit et ensuite pouvoir accéder via session[id][monobjet] depuis n'importe quel appel d'un utilisateur

2. serialize + mysql (MEMORY (HEAP))

Stocker dans une table mémoire mes objets serializés.


Quelles solution est la meilleure ?

Dans la solution 1 (session), les données sont en mémoire ou dans un fichier text ?

La solution 2 me semble plus performant mais quid de la performance de serialize ?

Une des différences est que si j'ai 1.000 connections sumultanée avec la solution 2, j'aurai 1.000X l'objet en mémoire et l'objets ne seras vraiment modifié qu'une fois l'objets remis en mémoire. Tandis qu'avec la solution 1... l'objets n'est présent qu'une seule fois.

La plus part des objets stockés ne seront pas souvent modifiés. Dico, pramaètre des modules. Cela se fera via la partie administration. Mais pour les stats... là il y aura modification. Je peux très bien utiliser 2 type de système de cache mais bon je préferais un seul.


Merci pour vos avis !

Bon je vois que le sujet n'interesse pas grand monde :roll:

J'ai réfléchit un peu plus à LA solution idéale !

Pour rappel :

Objectif: Avoir un espace mémoire partagé entre les utilisateurs ou se trouveraient les paramètres applications, table de dictionnaire, stats, etc. Pourquoi ? Pour éviter trop d'accès disque ou trop d'accès DB ou trop d'espace mémoire utilisé.

ex: Si 1000 personnes affiche une page au même moment, il y aura 1000X le dictionnaire en mémoire, je veux éviter cela.


J'ai proposé 2 solutions :

1/ Mémoire partagée via une session crée manuellement bidon pour y mettre les objets

2/ Mémoire se trouvant dans une table MySql HEAP (en mémoire centrale)


J'ai regardé cela d'un peu plus près et voici mes premières constatations :

SESSION:

Les variables contenues dans une session sont sauvegardées dans un fichier text (sérialisé). Lors de l'ouverture de la session, les données sont chargée en MC.

3 questions :

Si 10 personnes ouvre cette même session bidon, les objets se trouvent-ils 10X en MC ou bien une seul fois ?

Est-il possible d'acceder à 2 sessions en même temps : Session utilisateur, Session partagée ?

Est-il possible de sauvegarder ce fichier text en MC et non sur le disque ?

MySQL HEAP:

J'ai testé et premier constat, pas moyen de créer un champs de plus de 256 caractère dans un HEAP. Bref c'est pas gagné pour placer des tableaux style dictionnaire. De plus, si j'ai 1000x requêtes simultanées, j'aurai 1.000x l'objets en MC.

J'ai eu l'occasion de voir des statistiques d'utilisation d'une table HEAP et MyIsam et les différences ne sont pas énormes



Conclusion pour le moment : aucune des solutions ne me plait. Je voudrais une sorte de singleton (cf Java). Une classe avec variable static et persitant. Hélas je crois qu'en PHP cela n'existe pas. Le mots persitant ne se marie pas trop avec le PHP. J'epsère que certains expert pourront me donner leur avis sur la question. Est-il possible en php que 10 personnes accèdent au même tableau de donnée en MC ?


Merci pour ceux qui essaye de comprendre et de répondre !

Bonjour,

Le problème de php par rapport au java sur ce point là, c'est que (grosso modo) un script php correspond à un programme qui s'exécute. Donc, a priori il n'est pas possible via php de stocker des objets en mémoire entre deux requêtes.
Donc pour ton cache d'objet il va falloir passer par les fichiers (sessions, ou perso...) soit par la BD.

Pour la session, chaque client à sa propre session. Donc l'objet est chargé autant de fois qu'il y a de clients (logique car les sessions, en usage normal, doivent pouvoir évoluer indépendemment les unes des autres), Tu peux cependant utilisé un fichier commun a tous les clients et le charger dans un variable en début de script, mais il rique d'y avoir des problème d'accés ou de verrou sur des accés concurrents (à confirmer) en plus de problèmes de cohérence des données si le fichier est modifié entre temps (Des clients qui auront chargé les anciennes données, d'autres les nouvelles).

Pour la base de donnée je ne connais pas les tables HEAP donc je ne pourrai pas t'êre utile la dessus.

J'ai cru comprendre au détour d'un article traitant des performances d'accès que faire un select d'un champs dans une DB était plus rapide que d'ouvir un fichier text grace au cache et autre optimisation mysql.

Je vais donc opter pour la solution d'une table mysql MyIsam pour y stocker les objets sérialisés. Normalement ces données ne sont pas modifiée souvant mise à part pour les stats. Faudra que je fasse attention à ce que l'ouverture-traitement-écriture de l'objet stats soit rapide.

Pas de HEAP car champs limité et performance pas si terrible que ça. Et comme, quoiqu'il arrive, 2 utilisateurs ne peuvent pas acceder au même objets en MC, je vais spliter les dico suivant la langue mais aussi comme c'était prévus par module. Histoire de ne pas avoir des mots ou phrase qui ne sont pas utilisées en MC.

Quelqu'un sait si PHP6 permettra le partage de donnée en MC via un singleton ? C'est un gros manque tout de même ! :cry:

Quelques nouvelles....

J'ai découvert eAccelerator qui est basé sur mmcache. J'ai trouvé ça en fouillant de le code d'IPB vu que je savais que ce forum avait un système de cache.

Apparemment il s'agit bien d'un cache mémoire avec mémoire sur le disque mais il faut passer par un dll. J'ai réussi à l'installer et ça fonctionne. Comme je suis au début de la création du site je ne sais pas voir l'impact sur les perf mais je fais faire un pti bench histoire de voir ça.

Apparemment il est également possible de stocker des instances de classe. Ca m'interesse également car j'ai une class par fichier php. Si je charge ces instances dans le cache, plus besoin d'vourir à chaque requpete les fichier php sur le disque. Evidemment cela ne fonctionne que pour les instances de class outils ou de traitement et non pour les class avec des variables. Enfin je me comprends mais la majorité de mes classes sont dans le 1ier cas.

Je vais faire une loader de class qui remplacera mon require_once, $obj = new class; et me retournera l'instance sauvée dans la cache. en centralisant cela, je peux plustard facilement modifier cela si jamais c'était nécessaire.

Bon voila eAccelerator installé, class d'abstraction faite (do_get, do_post, etc) et la class d'outils presque terminée.

Ma classe d'outils gère l'accès aux données mise en cache à l'aide d'un tableau en cache nomé index et qui ressence toutes les données mises en cache ainsi que des infos sur leur fraicheur et quelle fonction il faut appeler pour les remettres à jour. comme ça, tout est transparent. Si j'accède à une info qui n'est pas présente ou obsolète, ça la mets à jour et me retourne évidemment l'info.

J'ai fais un test de performance sur l'accès à une donnée dans un fichier xml. Je crée une boucle qui tourne 100.000 X et qui accède à un élément en 3ième niveau d'arborescence. C'est un très petit fichier xml, 2Ko. Et j'ai rit lors des tests.

+/-10sec pour 100.000 accès en cache
+/-14sec pour 100.000 accès à l'xml. bien 40% de mieux sauf que... je me suis trompé. La première fois que j'ai lancé le test avec accès xml le portable a planté et j'ai du rebooter et pour une raison que j'ignore, il a pas concervé la version 100.000 X mais 10.000 X

Donc en fait accès xml 14sec pour 10.000 accès et avec la cache 100.000 pour 10 sec. Je crois que ça en valait la peine donc.

J'ai également fait un test sur l'accès à un tableau en cache.

Pour accéder à un élément d'un tableau, il faut mettre dans une variable le tableau et ensuite retourner l'élément demandé. J'ai donc fait 3 class,

getElem1(tab,id1) retourne l'élement tab[id1]
getElem2(tab,id1,id2) retourne l'élement tab[id1][id2]
getElem3(tab,id1,id2,id3) retourne l'élement tab[id1][id2][id3]


L'idée est de savoir si c'est mieux dans la fonction d'accès de demander tout le tableau ou juste l'élement dont j'ai besoin. Le but étant d'avoir le moins d'élement en mémoire en même temps

Mais les test n'ont pas été très révelateurs car j'ai seulement fait des test avec une requête. Pour voir faite un vrai test, il faudrait simuler 10.000 accès en même temps pour voir effectivement l'avantage.

Je devrais normalement faire de nouveaux tests pour le dictionnaire. J'ai un fichier dico par module et la question est de savoir si c'est mieux de charger le dico d'un module en GLOBAL tout au long tu traitements et génération de la page ou de faire appel à getElem sur la cache pour chaque accès à un mots. L'avantage de la seconde solution est que l'occupation mémoire est moindre mais quid des performances ? Je vous tiens au courant. Même si ça n'a pas l'air d'interesser beaucoup de gens. :aie: