Bibliothèques de gestion du cache

Salut,

Je viens récemment de terminer un projet sur lequesl j'ai eu fort à faire avec les libs de cache.
Ou plutot de stockage persistant avec ttl. genre Memcache, apc, fichier ect

Bref, au départ j'utilisais cache lite, qui enregistre dans des fichiers, le support segment mémoire étant en béta.
Hors, ce stockage en fichier n'était pas du tout concluant, car beaucoup trop lent.
J'ai bien cherché ici et là, mais je n'ai pu trouver sur une librairie pour faire cela dans des segments mémoire.
Aussi ai je dû mettre les mains à a patte pour faire ma lib......

Mais je reste perplexe, il doit bien exister des librairies pour faire cela ? quelles sont elles ? Et surtout, quelles sont les solutions que vous utilisez vous dans vos projets ?

a plus

bah alors, même les utilisateurs de ZF et autres symphony&&consors n'ont pas ce genre de problématiques ?
Ce sont pourtant des frameworks construit pour du lourd ?

J'utilise memcached à deux niveaux (disons plutôt que j'expérimente) :
- Directement par le serveur (nginx)
- Dans le code php avec l'extension Memcached

Le stockage n'est pas persistant, du moins, il l'est le temps que le deamon est lancé. Si tu veux quelque chose qui persiste au delà d'un reboot, memcached ne fera pas l'affaire.

Citation:

---

Envoyé par metagoto

J'utilise memcached à deux niveaux (disons plutôt que j'expérimente) :
- Directement par le serveur (nginx)
- Dans le code php avec l'extension Memcached

Le stockage n'est pas persistant, du moins, il l'est le temps que le deamon est lancé. Si tu veux quelque chose qui persiste au delà d'un reboot, memcached ne fera pas l'affaire.

---

Salut metagoto,

Je me suis mal exprimé désolé.
J'utilise actuellement des systèmes, que je considère comme persistant, puisque rémanent a >1 requêtes HTTP.

Pour infos, j'utilise memcache, et apc en même temps, ils forment un couple de cache L1 / L2.
Chacun s'occupant d'un type de caching spécifique.
APC pour le caching de recordSet, memcached pour le caching de code généré, résultats sql ect.
Pourquoi ?
Parce qu'APC par définition est plus rapide que memcache en lecture.
Cela vient plus du fait que memcached fonctionne en réseau / ou socket, là ou apc fonctionne uniquement à travers l'api de php.
L'utilisation de l'API est bien plus rapide que les sockets / connexions réseaux.
APC est donc plus efficace pour créer un écran de fumée des resulats de recordset car pour générer une page je génère beaucoup de recordset (+ d'une 100aines).
Alors que je génère finalement peu de requête sur des parties code HTML généré en cache (pas plus d'une 20 aines).

Enfin j'ai toujours un troisième système de cache sous forme de tableau PHP. Mode de caching encore plus rapide que les segments mémoire.
Celui ci permet de soulager d'autant les requêtes faites sur les systèmes de caching.

Bref, j'utilise une forme de hiérarchie.


Autrement, comme je le disais, lorsque j'ai eu à dèv mes libs de stockage dans ces différents espaces, j'ai été surpris de ne pas trouver des libs plus aboutis sur le sujet, ou même de ne simplement pas en trouver.

De la même manière je suis étonné qu'aussi peu de gens utilise un système de cache à base de segment mémoire.... 2 personnes sur la floppée d'utilisateurs php sur dvp c'est peu, non ?


Tu peux me donner quelques infos sur nginx stp ?
Perf, scalability, et cet étonnant segment mémoire qu"il semble proposer :o ?


Aussi pour ceux qui utilisent memcached, mode distribué, ou mode centralisé dans vos archis ?
En ce qui me concerne mode distribué, un serveur par front... Il y à des avantages, et des inconvénients. A discuter si cela intéresse quelqu'un.

merci,


a plus

kaymak

Pour nginx, le plus simple c'est que tu ailles voir ces sites:
http://nginx.net/ (site officiel)
http://wiki.nginx.org/Main (semi officiel wiki. Doc en anglais. La doc de référence étant en russe)
http://fr.wikipedia.org/wiki/Nginx

nginx est sensé écraser la concurrence tant en performance qu'en impact sur les ressources... si le nombre de processes cgi pré forkés est suffisant. Arrivé à cette limite, les performances chutent (mais les ressources consumées restent stables). Pour cette raison, il est parfois utilisé comme simple proxy en amont de apache.

nginx a un module qui permet de communiquer avec memcached. nginx en tant que tel ne fait pas de caching.

J'avais désactivé APC depuis que j'utilise php 5.3 (et donc les beta). Ca posait problème en fast-cgi. Je compte bien réactiver cette extension parceque c'est vrai que c'est beaucoup plus véloce que memcached.

Pour le coup, j'utilise memcached en unix sockets. Fut un temps où le daemon (juste un seul) tournait sur une autre machine et là c'était donc en réseau.

J'utilise mes propres "libs" (je dirais composants) pour gérer le caching. Un simple layer en fait pour différents backends. Il me semble que beaucoup de frameworks proposent leur composants de caching qui s'interfacent avec les différentes solutions existantes (notamment APC). Personnellement, je trouve que la principale difficultée n'est pas l'abstraction du système de caching car à l'usage ça se résume souvent au simple couple clé/data. Le plus chaudard, je trouve, c'est comment intégrer ça de manière transparente, si possible, à une architecture existante, sans même prendre en considération le fait que ces backends puissent être distribués.

Citation:

---

Le plus chaudard, je trouve, c'est comment intégrer ça de manière transparente, si possible, à une architecture existante, sans même prendre en considération le fait que ces backends puissent être distribués.

---

[Strike]Ben un moyen de cacher à la serpe, serait de faire un hash de get / post / cookies / url / session.
Avec les sessions sur une mémoire distribuée c'est faisable. Et à la rigueur tu n'aurais même pas besoin de connaitre l'état de l'application à exécuter, cela pourrait se faire en complete blackbox.
Du moment que tu places un proxy devant le serveur apache effectif.
Qu'est ce t'en penses ?[/Strike]

en fait c'est con comme (mon) idée. A part en l'implémentant dans les diverses briques de code, je ne vois pas de solution tout court.
La raison est que la session contiendra nécessairement un identifiant de l'utilisateur, le cookie aussi par ailleurs, puisqu'il contient l'id de session. Ça rend donc caduque toute mise en cache.

Et de toute manière ce n'est pas une solution viable, mettre en cache à la serpe. A partir du moment ou tu personnalises ton affichage tu es obligé de descendre dans l'application pour définir des conditions de mise en cache pour gérer plus finement ton affichage.
Dès lors il reste peu de chose à faire à part avoir un bon framework pour te pousser à développer <par fragments> (template, include, mvc).
Le reste ce n'est plus que de l'association clef/data/ttl effectivement.

Hmm et désolé de ma longue absence, le sujet est intéressant !