> 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.
C'est à la fois vrai et faux. Redis a d'abord été conçu pour être une
key based database, mais le second article que je citais[1] est écrit
par Salvatore Sanfilippo, un des core devs de redis. Tout l'article
concerne justement les nouvelles features qu'il avait introduit alors
dans redis pour en faire un server de caching.
Maintenant, c'est vrai que les limites de cette implémentation
apparaissent avec le nouveau système de caching de rails. Cette phrase
m'interpelle :
For default three keys are sampled, that is a reasonable
approximation of LRU in the long run
Je me demande ce qu'il signifie par là. L'interprétation que j'en ferais
est que lorsque la mémoire est pleine, la plupart des items en cache
sont périmés, et que donc cela doit être safe de virer le plus vieux
dans un lot de 3 éléments pris au hasard.
Toute la question est de savoir ce qui serait le plus performant :
1. checker toutes les clefs à chaque insertion pour trouver la plus
vieille (memcache)
2. en retirer au hasard, quitte à en supprimer une récente de temps en
temps (ce qu'il faut mesurer étant à quelle fréquence cela arrive, parce
que ça implique un long temps de régénération de l'item caché)
Ça mérite un benchmark, je vais inspecter ça ce week-end.
Bottom line : si 2. s'avère est plus intéressant, c'est tout à fait ok
d'utiliser redis avec le russian doll caching.
Je ne peux cela dit m'empêcher de me dire que l'une est l'autre des
solutions sont dépassées en terme de performance comparé à la solution
qui consisterait à avoir un worker qui supprime toutes les clefs
périmées : pas besoin de lire le timestamp des clefs si la mémoire n'est
jamais saturée.
> 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).
Oui, je l'utilisais avant de passer à redis. J'ai switché suite aux
nombreux reports que disant redis était beaucoup plus performants.
... les aleas du hypeness :)
[1]http://oldblog.antirez.com/post/redis-as-LRU-cache.html
On Monday, September 2, 2013 5:32:59 PM UTC+2, gdurelle wrote:
>
> 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 .
