Manual:Memcached/fr

memcached est un objet en mémoire de type dépôt que MediaWiki peut utiliser pour mettre des valeurs en cache, afin de supprimer le temps nécessaire aux calculs très longs et pour réduire la charge des serveurs de bases de données.



Quand faut-il l'utiliser ?
Pour un petit site Web hébergé sur un seul serveur, l'installation de Memcached n'en vaut peut-être pas la peine. Dans de tels cas, envisagez de configurer MediaWiki pour utiliser l'APCu de PHP à la place comme magasin d'objets principal. Pour les grands sites Web comme Wikipedia et en général pour les wikis hébergés par plusieurs serveurs Web, Memcached est un choix courant pour le cache d'objets de MediaWiki.

Pour d'autres informations concernant les options du cache dans MediaWiki, voir le paragraphe Mise en cache des objets du manuel des performances.



Installer Memcached
La plupart des gestionnaires de packages pour Linux et macOS proposent des archives prêtes à l'emploi pour Memcached (y compris pour Debian, Fedora et Ubuntu).

Si aucune archive n'est disponible pour votre distribution, il vous faudra la compiler à partir des sources en les téléchargeant depuis memcached.org. Pour compiler à partir des sources, libevent est nécessaire. Memcached et libevent sont des projets open source publiés sous des licences de type BSD.

Pour d'autres informations générales concernant Memcached, voir aussi Memcached sur Wikipedia.

Sécurité
Memcached n'a aucune sécurité ni authentification. Veuillez vous assurer que votre serveur est correctement protégé par un pare-feu et que le ou les ports utilisés pour les serveurs memcached ne sont pas accessibles au public. Sinon, n'importe qui sur Internet peut écrire des données et lire dans votre cache.

Un attaquant familier avec les composants internes de MediaWiki pourrait l'utiliser pour se donner un accès développeur et supprimer toutes les données de la base de données du wiki, ainsi que pour obtenir les hachages des mot de passe et les adresses courriel de tous les utilisateurs.



Client PHP pour Memcached
Au moment d'écrire ces lignes (MediaWiki 1.27), MediaWiki utilise un client memcached en PHP pur (basé sur le travail de Ryan T. Dean). Il prend également en charge l'extension PECL php-memcached. Pour utiliser Memcached avec MediaWiki, PHP doit être compilé avec  (valeur par défaut).

Pour en savoir plus sur la manière de choisir Memcached comme base arrière pour les différentes parties de MediaWiki, voir La mise en cache du manuel.

Configuration
Si vous voulez commencer petit, exécutez simplement une instance de memcached sur votre serveur Web : memcached -d -l 127.0.0.1 -p 11211 -m 64

(pour fonctionner en mode daemon, accessible uniquement via l'interface loopback de bouclage, sur le port 11211, utilisant jusqu'à 64 Mo de mémoire)

Dans votre fichier LocalSettings.php, définissez :

Le wiki va ensuite utiliser memcached pour mettre en cache différentes données. Pour utiliser plusieurs serveurs (machines physiquement séparées ou des caches multiples sur une machine x86 avec beaucoup de mémoire ou Power box), ajoutez simplement d'autres éléments dans ce tableau. Pour augmenter le poids d'un serveur (disons, parce qu'il a deux fois plus de mémoire que les autres et que vous voulez répartir équitablement l'utilisation), faites de son entrée un sous-tableau :

SELinux
Plusieurs règles sur Memcached existent pour les systèmes avec SELinux. Pour autoriser Apache (httpd) à accéder à Memcached, vous devez définir les règles suivantes :

setsebool -P httpd_can_network_memcache 1

Résolution des problèmes


Perte des données session lors de la sauvegarde
Si vous stockez les données session dans memcached et que les utilisateurs voient le message suivant par intermittence lorsqu'ils veulent sauvegarder leurs modifications :

cela signifie qu'un ou plusieurs de vos serveurs memcached peuvent avoir un fichier  mal configuré. Vérifiez sur chaque serveur memcached que son propre hostname vaut bien localhost:

127.0.0.1 servername.here localhost localhost.localdomain ...

Sinon le serveur ne peut pas se connecter à son propre processus memcached.



Utiliser memcached dans votre code
Si vous écrivez des extensions qui réalisent des requêtes coûteuses en temps dans la base de données, il serait utile de les mettre en cache avec memcached. Il existe plusieurs manières principales d'obtenir un gestionnaire de memcached :


 * ...à utiliser si vous voulez un cache en mémoire qui soit partagé, avec des possibiltés de purge explicite afin de stocker des valeurs dérivées de sources persistentes
 * ...à utiliser si vous voulez un magasin en mémoire qui soit éphémère et non partagé avec les autres centres de données
 * ...à utiliser si vous voulez un cache en mémoire qui soit éphémère et non partagé avec les autres centres de données
 * ...à utiliser si vous voulez un cache quelconque qui soit ou ne soit pas dédié à un centre de données, même si celui-ci est émulé et qu'il utilise une base de données SQL. Notez-bien que vous pouvez à la place, recevoir un gestionnaire qui communique avec Redis, APC, MySQL ou d'autres dépôts. L'utilisation du mot memcached est due historiquement à l'API définie autour des simples commandes prises en charge par memcached et au fait que aujoud'hui, memcached est normalement le meilleur magasin de caches à usage général.

Les extensions avec des besoins spécifiques (comme la persistence) doivent définir de nouveaux paramètres de configuration tels que  ou. Le code qui utilise les caches peut les fournir à  et   respectivement.

L'extrait de code suivant montre comment mettre en cache les résultats d'une requête dans la base de données avec memcached pour 15 minutes mais interroge d'abord memcached pour avoir les résultats au lieu de lire la base de données.

Les classes abstraites BagOStuff et WANObjectCache définissent et documentent toutes les fonctions disponibles :





Anciennes notes de développement
D'une manière générale, on a envie de placer beaucoup de données dans le cache, faites-le à chaque fois que vous pouvez et expirez-les automatiquement dès qu'il y a des modifcations de faites.



Modèle d'expiration

 * explicit expiration times: memcached lets us set an expiration time on an object when we store it. After the time is up, another request for the object will find that it has expired and return nothing to us.
 * pro: last-ditch fallback to let data that could be updated badly eventually fall out of the cache
 * con: we have to know ahead of time when it will cease to be invalid. hard to do when we're dealing with user edits!


 * delete cached objects when we know we're doing something that will cause them to be invalid but are not in a position to update them while we're at it
 * pro: fairly simple; the item will be reloaded from the database and recached when it's next needed
 * con: if this will affect a large number of related items (for instance, creating or deleting a page invalidates the links/brokenlinks tables and rendered HTML cache of pages that link to that page) we may have to hunt them all down and do a lot of updating


 * include timestamps on cached objects and do our own expiries based on dependencies
 * pro: can expire many objects at once by updating a single node they depend on
 * con: more things to load; multiple dependencies could be trickier to work with

Questions & Answers
Q: Can I search on part of a key or a regular expression on a Memcached server?

A: No, you can only search for an exact key if you need more information on what you could possibly do you can check out the Memcached protocol

Q: Can I have multiple wikis point to the same Memcached server?

A: Yes, as long as each have different wiki-ids ($wgDBname). Certain cache keys are intentionally shared in such a scenario, such as rate limiting stuff.