Linux Attitude

Niveau :      
Résumé : memcached (bis)

Dans un précédent article j'expliquais ce qu'était memcached et comment l'utiliser. Nous allons maintenant nous enfoncer un peu plus dans les détails.

Performances

Tout d'abord parlons performances. Commençons par utiliser les bonnes options :

• utilisez autant de thread que votre machine a de coeurs (option -c)
• utilisez autant de ram que possible en n'oubliant pas d'en laisser aux autres applications s'il y en a (option -m)

Si vous utilisez memcached localement sur une seule machine, utilisez l'option -s pour sauter toute la pile tcp/ip et gagner un peu en performances.

Ensuite vous devez modifier votre code pour cacher un maximum de choses, encore faut-il que cela vaille le coup. Heureusement mettre en place le cache et le désactiver est très rapide, vous pouvez donc mesurer facilement vos gains. Sur un site web chargé, il est conseillé de cacher en premier les résultats des requêtes SQL. Mais il peut aussi être judicieux de cacher un tableau, voire toute une page, car elle est probablement une agrégation de plusieurs requêtes SQL (et rien ne vous empêche de faire les 2, voire de mettre des cache partout où vous pouvez). Mais n'oubliez pas, faites des mesures, c'est le meilleur moyen de savoir si votre cache sert à quelque chose.

Choisir quoi cacher est finalement assez simple : la partie la plus grosse possible de la page pouvant être partagé par le plus de monde possible. Donc choisir des éléments ne dépendant pas de l'instant présent. Par exemple ce n'est peut-être pas une bonne idée de cacher une page dépendant d'une session, sauf si votre utilisateur est sensé rester longtemps sur votre site. Contre exemple, quelque chose qui vu par tout le monde mais qui dépend de l'heure qu'il est (le dessin de votre horloge analogique par exemple).

Si votre cache est uniquement local, il peut être plus intéressant d'utiliser une bibliothèque dans votre processus que memcached. Comme le mesure ce site : http://www.mysqlperformanceblog.com... l'api cache interne de php serait 30 fois plus rapide que memcached.

Si votre cache n'est pas uniquement local mais que vous avez toujours des problèmes de performances, il peut être utile d'empiler plusieurs niveaux de cache (local puis distribué).

Et enfin optimisez l'usage de votre cache pour faire en sorte que le maximum de choses demandées au cache s'y trouve déjà. Pour cela faut mesurer son utilisation. Memcached enregistre déjà les mesures et propose une commande pour retourner les résultats.

# on se connecte au démon et on envoit la commande stats
$ telnet localhost 11211
stats
....
END

Si le ratio get_misses/get_hits est élevé (plus de 20%) il est probable que votre cache ne soit pas optimisé au mieux (faites le ratio des différences et non le ratio tout court pour grapher sur une longue durée). Le but est de le garder le plus petit possible, les riches utiliseront même suffisamment de machines et de ram (et de code) pour qu'il atteigne 0%.

Distribution

Un cas particulier dans la gestion des machines doit attirer votre attention. Comme dit au numéro précédent, c'est le client qui gère la répartition des données sur les différentes machines. Ce qui veut dire qu'il n'est pas au courant lorsqu'une des machines tombe. Dans ce cas un Nième du cache disparaît, et il n'est plus possible d'écrire dans cette portion du cache. La solution évidente serait de faire en sorte que les clients soient synchronisés et se mettant d'accord sur la liste des machines régulièrement. Mais attention, remanier la liste des machines implique que l'algorithme de choix des machines a changé, il faut donc invalider tout le cache.

Mais en changeant l'algorithme utilisé coté client, il est possible de s'éviter se problème, la technique est décrite ici : http://amarok.kde.org/blog/archives...

Fin

Notez que votre distribution doit vous fournir un fichier nommé protocol.txt décrivant le protocole utilisé par memcached. Vous pourrez ainsi jouer avec telnet ou coder votre propre client.

Et enfin n'oubliez pas de lire la FAQ