Zend FR

fred wolf · 19-04-2007 15:41:13

Bonjour la Communauté,

Pour moi, il ya avant et après ZF. Je veux dire qu'en testant les différents modules, j'ai découvert des concepts que je n'avais pas explorés avant.
Notamment la notion de cache...Je suis bluffé par les perfs. Du coup, j'utilise Zend_Cache à toutes les sauces dans mon appli en cours.
Comme la consultation est plus importante dans mon cas que les écritures en base, chaque fois que quelqu'un consulte une structure en base (c'est mon entité principale, qui fait appel à 15 autres entités pour récupérer toutes les infos... vous imaginez les requêtes...), je mets en cache le résultat. Et je ne regénère le cache que dans le cas où une structure est modifiée ou supprimée. J'obtiens de cette manière une fluidité dans la navigation qui ne cesse de m'impressionner.
J'envisage d'utiliser Zend_Cache pour les traductions en base également, mais peut-être m'emballe-je ?

BREF, ceci m'amène à me poser plusieurs questions :

Y-a-t-il une limite en théorie à la taille à allouer au cache ?
Combien de fichiers peut-on mettre en cache raisonnablement ?
Faut-il implémenter un mécanisme qui permet de limiter la taille du cache que l'on veut allouer e tq ui prévient quand on en approche ?

Désolé pour ce préambule fastidieux, mais les bonnes âmes pourront me dire si cette méthode leur semblent judicieuse ou pas

A bientôt

fred

philippe · 20-04-2007 09:02:00

Bonjour,
Je n'ai pas encore regardé Zend_Cache, mais pour le cache en général il y a quelques principes généraux :

=== Les défauts ===
* plus le cache est gros, plus il est lent. Si ton cache est trop gros, il ne sera pas forcément plus rapide que ton code de base
* si le cache est en mémoire, il ne faut pas qu'il fasse partir ta machine en swap
* si tes données bougent beaucoup, ça ajoute du temps d'écriture
* ça complexifie le code

=== Les avantages ===
* ben euh... ça va plus vite...
* ça peut décharger ta base de données (en cas de gros trafic, c'est bcp plus facile de mettre 5 frontaux apache/PHP que de duppliquer sa base...)

Voilà... c'est très général, mais c'est les implications principales que je vois...

A+, Philippe

fred wolf · 20-04-2007 11:40:25

plus le cache est gros, plus il est lent. Si ton cache est trop gros, il ne sera pas forcément plus rapide que ton code de base

Dans mon cas d'utilisation, le but est d'obtenir un tableau qui reflète la représentation hiérarchique de l'info que je passe à Smarty après (c'est ça que je mets en cache).

Je ne vois que deux solutions :

* avec ma requête qui contient 15 (voire plus) join, je me retrouve avec plus de 1000 enregistrements pour 1 structure (résultat du produit cartésien !) que je dois parser pour imbriquer les data dans un tableau,

* Ou alors je fais 15 requêtes, et je pousse le résultat directement dans un tableau.

Donc, le temps de traitement est assez gros. Avant que l'accès au cache (sur le disque) dépasse le temps d'accès à la base, je crois que j'ai de la marge...

si le cache est en mémoire, il ne faut pas qu'il fasse partir ta machine en swap

Brrr...ça me fait trop peur le cache en mémoire, je ne vaux même pas y penser J'imagine même pas les implications du serveur qui part en swap...

si tes données bougent beaucoup, ça ajoute du temps d'écriture

CA C'EST LE GROS PROBLEME, surtout si les utilisateurs ont tendance à enregistrer à tout va (j'enlève un blanc dans la zone Commentaires, je rajoute un retour à la ligne, tiens j'avais oublié une majuscule...).

Mais si la plupart du temps il s'agit de consultation, c'est jouable, (dans mon cas 70/30, les utilisateurs ont surtout besoin de réactivité en consultation, avec quelqu'un au téléphone par exemple).

En outre, arrêtez moi si je me trompe le cache est accessible par tous les utilisateurs (qui ont les droits bien sûr...), donc pour du temps perdu à l'écriture pour une personne, plus autres en gagnent à la consultation.

ça complexifie le code

Oui, c'est vrai. Surtout si on veut la jouer finement. Ce qui me fais un peu peur aussi, c'est que, pour une écriture dans la base, pas de problème, avec les transactions et les relations d'intégrité, je peux dormir sur mes deux oreilles, mais c'est autre chose pour l'intégrité du cache.

Voilà, dites-moi ce que vous en pensez.

Le problème c'est que ce parti pris a une grosse implication sur la façon d'architecturer l'appli, il ne s'agit pas de se rendre compte après trois mois, que ça ne tient pas la route. J'avoue que ça me fait un peu flipper, c'est pour ça que si vous avez une expérience (ou des idées ) dans ce domaine, n'hésitez pas !

Bien à vous,

fred

crimso · 09-08-2007 20:13:35

Bonjour,

j'allais mettre mon grain de sel avant de voir la date du poste.
Du coup je réponds par une question : Alors ? 4 mois plus tard, ça tient la route ou pas ?

merci

ubini · 03-04-2010 00:38:59

Oui, cela m'intéresse aussi de savoir ce que cela donne a plus grande échelle. Alors je remonte ce vieux poste, désolé

J'ai aussi une autre question. Est-ce que c'est mieux de gérer un seul gros cache ou plusieurs plus petits ?

Zend FR

#1 19-04-2007 15:41:13

A propos de Zend Cache et du cache en général....

#2 20-04-2007 09:02:00

Re: A propos de Zend Cache et du cache en général....

#3 20-04-2007 11:40:25

Re: A propos de Zend Cache et du cache en général....

#4 09-08-2007 20:13:35

Re: A propos de Zend Cache et du cache en général....

#5 03-04-2010 00:38:59

Re: A propos de Zend Cache et du cache en général....

Pied de page des forums