Ouaip effectivement c'est pas top, du coup t'es obligé de foutre des sweepers à la main dans ton appli :s
J'utilise aussi Redis mais que pour Sidekiq (ça torche vraiment bien en perfs ;)) Mais comme on vient effectivement de me le faire remarquer Redis n'est pas vraiment fait pour le cache : C'est de la base de donnée persistente. Ce qui t'oblige à faire le sweep toi même. Cool pour des workers, mais pas du tout pour du cache. Je n'ai jamais eu à mettre les mains dans Memcache, ça marche pas mal tout seul (magie), donc hésite pas tester (ou un autre serveur de cache). Chuussss Le lundi 2 septembre 2013 11:47:07 UTC+2, Olivier El Mekki a écrit : > > Hello, > > Personnellement, je suis resté à l'ancien système de caching lors de la > migration vers rails-4, en ajoutant les gems. Le nouveau système est > beaucoup plus simple à utiliser mais il me semble un peu trop simpliste: > je n'ai pas forcément envie d'associer une fragment caché à une > ressource, et je veux pouvoir stocker de la logique complexe > d'invalidation (ce qui a naturellement sa place dans un sweeper). Ça > reste un bon système pour encourager ceux qui ne cachent pas déjà leur > contenu à le faire, cela dit. > > > Il y a également quelque chose qui m'inquiète, avec le russian doll > caching : il est pensé pour memcache. J'ai pris l'habitude d'utiliser > redis (notamment parce que j'utilise resque), et ce passage par dhh a > retenu mon attention[1] : > > 4. This generates a lot of cache garbage. Once we’ve updated the > todo, the old cache will never get read again. The beauty of that > system is that you just don’t care. Memcached will automatically > evict the oldest keys first when it runs out of space. It can do > this because it keeps track of when everything was last read. > > > Cela semble donc indiquer que rails ne cherche jamais a supprimer les > clefs, il compte seulement sur memcache. Or, si un tel système de > suppression des clefs les moins récemment lues (LRU) lorsqu'il n'y a > plus de place existe bien sur redis, il a de sévères limites[2] : > > In order to save memory Redis just adds a 22 bits field to every > object for LRU. When we need to remove a key we sample N keys, and > remove the one that was idle for longer time. For default three > keys are sampled, that is a reasonable approximation of LRU in the > long run, but you can get more precision at the cost of some more > CPU time changing the number of keys to sample. > > ce n'est pas la plus vieille clef dans toute la db qui est supprimée, > mais redis prend un set de N items au hasard (3, par défaut) et supprime > le plus vieux. > > J'ai peur que cela ne cause des problèmes, dont les symptômes seraient > que des pages supposées être cachée soit regénérées souvent, lorsqu'on > se promène sur un site. > > Quelqu'un a des retours là dessus ? Le net est incroyablement silencieux > à propos du russian doll caching vs redis. > > > [1] > https://37signals.com/svn/posts/3113-how-key-based-cache-expiration-works > [2] http://oldblog.antirez.com/post/redis-as-LRU-cache.html > > > On Monday, September 2, 2013 11:10:48 AM UTC+2, gdurelle wrote: >> >> Hello, >> >> Encore un pti billet sur Rails 4 :) >> >> http://gdurelle.com/post/60058329677/le-russian-doll-caching-en-rails-4 >> >> J'aimerai bien savoir si certains d'entre vous on eu les même problèmes, >> et si vous les avez résolus autrement ? >> >> Chuuussss >> > -- -- Vous avez reçu ce message, car vous êtes abonné au groupe "Railsfrance" de Google Groups. Pour transmettre des messages à ce groupe, envoyez un e-mail à l'adresse [email protected] Pour résilier votre abonnement envoyez un e-mail à l'adresse [email protected] --- Vous recevez ce message, car vous êtes abonné au groupe Google Groupes Railsfrance. Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse [email protected]. Pour plus d'options, visitez le site https://groups.google.com/groups/opt_out .
