mercredi 28 août 2013

Play Framework et les Tests Unitaires



Depuis quelques jours, je joue avec Play!, un framework web Java.
Il possède plusieurs avantages forts sympathiques je trouve:

  • Stateless
  • REST
  • Asynchrone
  • Intgérant nativement Junit
Et c'est de ce dernier point en particulier que je vais parler aujourd'hui car l'intégration n'est pas si native que cela et je suis tombé sur plusieurs bugs gênants.

play test ne fait rien


La méthode conseillée pour lancer les tests est la commande "play test" mais malheureusement avec la version 2.1.3, cette commande ne teste absolument rien. Gênant ce bug...
Pour contourner cela il est nécessaire d'ajouter dans le fichier project/Build.scala les lignes suivantes:


val appDependencies = Seq(
    // Add your project dependencies here,
    javaCore,
    javaJdbc,
    javaEbean,
    "play" %% "play-test" % play.core.PlayVersion.current % "test" exclude("com.novocode", "junit-interface"),
    "com.novocode" % "junit-interface" % "0.9" % "test"
)


Ce problème devrait être corrigée dans la 2.1.4 qui ne devrait pas tarder à sortir.

play test se bloque lors des tests IHM


Il est possible avec Play! Framework de réaliser des tests fonctionnels en testant directement une page de notre application. Pour cela on utilise un testbrowser (cf la documentation sur le sujet).

Malheureusement si l'on fait cela avec la version actuelle de Play! Framework cela va bloquer entièrement la commande "play test" qui ne sera donc plus très utile.

Cela est dû à une incompatibilité avec la version de JQuery livré avec Play! Framework d'après ce bug.
La seule façon de débloquer cela est de télécharger la version 1.8.3 de jquery et de l'ajouter dans le dossier public/javascript en remplacement de la version 1.9.0 (ne pas oublier de mettre à jour vos pages aussi).

Lancer les tests unitaires depuis Eclipse


La commande "play test" est sympathique mais il arrive très régulièrement que l'on souhaite lancer uniquement un test ou une classe de tests depuis notre Eclipse et là malheureusement cela ne marche pas comme attendu à cause de l'erreur suivante:


java.lang.IllegalStateException: Class [class play.db.ebean.Model] is enhanced and [class models.Company] is not - (you can not mix!!)



Pour corriger cela il est nécessaire de télécharger le jar d'ebean et de l'ajouter en tant que paramètre par défaut dans Eclipse. Pour cela il est nécessaire d'aller dans Preferences > Java > Installed JRE > Edit et d'ajouter la ligne suivante:


-javaagent:/path/to/ebean/ebean-2.7.3-agent.jar



Et voilà ça devrait mieux aller !


Vraiment ? Pas dans tous les cas en fait. Il peut arriver que suite à cela un test soit cassé car lors d'un select en base via Ebean qui renvoie un objet avec un champ null.
Dans mon cas il s'agissait d'un champ Text (ou @Lob pour Ebean) qui était systématiquement vide alors que l'objet inséré le contenait bien.

Pour corriger cela il faut passer le champ concerné en private et générer soit même les getter/setter au lieu de laisser Play! le faire tout seul.
Et c'est tant mieux, je n'aime pas le fait d'avoir l'ensemble de mes champs public ça casse un peu le principe de l'encapsulation.

Fichier "init-data.conf" non trouvé


Si vous avez suivi les tutoriels du site Play! Framework vous avez vu que l'on peux ajouter facilement des données aux tests ou à l'application en cours de développement en créant un fichier Yaml dans le dossier conf/ et contenant l'ensemble des éléments à créer en base.

Le problème étant que si l'on fait les tests ensuite via Junit dans Eclipse il ne va jamais trouver ce fichier et donc ne va pas précharger votre base de données...

Pour corriger cela il faut ajouter le dossier conf au classpath d'Eclipse car celui-ci n'est pas ajouté lors de la commande "play eclipse".

Pour l'ajouter il suffit de faire un click droit sur le dossier conf/ dans le projet et choisir "Build Path" > "Use as Source Folder".

Je veux le coverage de mon code !


Maintenant que l'on a des tests qui fonctionnent que ça soit via la commande play test ou dans Eclipse on aimerait bien avoir également la couverture de code que l'on teste. Nous allons utiliser jacoco pour générer notre coverage.

Pour cela il faut ajouter plusieurs éléments à notre configuration:

  • Dans le fichier project/plugins.sbt ajouter les lignes suivantes:
libraryDependencies ++= Seq(
  "org.jacoco" % "org.jacoco.core" % "0.5.9.201207300726" artifacts(Artifact("org.jacoco.core", "jar", "jar")),
  "org.jacoco" % "org.jacoco.report" % "0.5.9.201207300726" artifacts(Artifact("org.jacoco.report", "jar", "jar")))

addSbtPlugin("de.johoop" % "jacoco4sbt" % "1.2.4")
  • Dans le fichier project/Build.scala:
  • Ajouter sous les import déjà existant les lignes suivantes:
import de.johoop.jacoco4sbt._
import JacocoPlugin._
  • Ajouter sous le bloc "val appDependencies = Seq(...)" une ligne:
lazy val s = Defaults.defaultSettings ++ Seq(jacoco.settings:_*)


  • Puis modifier le dernier bloc pour qu'il ressemble à cela (attention à bien ajouter le paramètre settings = s):
val main = play.Project(appName, appVersion, appDependencies, settings = s).settings(
    
    parallelExecution     in jacoco.Config := false,    
    jacoco.reportFormats  in jacoco.Config := Seq(XMLReport("utf-8"), HTMLReport("utf-8")),    
    jacoco.excludes       in jacoco.Config := Seq("views.*", "controllers.Reverse*", "controllers.javascript.*", "controllers.ref.*", "Routes*")
  )



Et voilà la couverture peut maintenant être générée via la commande:

play jacoco:cover



L'ensemble des fichiers seront placés dans le dossier /target/scala-2.9.1/jacoco/html.


Petit exemple du look:





Post 11/52

lundi 26 août 2013

QTodoTxt: une application pour todo.txt simple, rapide et multiplateforme




Aujourd'hui j'aimerai vous parler d'un sujet qui me tient particulièrement à coeur à savoir l'organisation personnelle et en particulier "Getting things done" (GTD).


J'ai découvert ce système et lu le livre allant avec il y a 3 ans alors que je cherchais une méthode un peu plus évoluée afin de gérer mes actions et projets au mieux. Cela m'aide beaucoup afin de ne pas tout reporter au lendemain ni de conserver en tête toute la liste de choses que j'ai à faire.
Du coup cela me libère l'esprit et me permet de me concentrer sur ce que je fais à l'heure actuelle. En plus de ne rien oublier, je suis plus efficace dans ce que je fais, que du bénef !


Par contre il me manquait un outil me permettant d'appliquer cette méthode au quotidien. Mon cahier des charges était assez simple (enfin je pensais):

  • Libre
  • Fonctionnant sur Android, Linux et Windows
  • Permettant de synchroniser mes tâches entre mes différents appareils
  • Avec une interface utilisateur simple
En ce qui concerne la partie mobile et la synchro (via Dropbox) j'ai trouvé assez rapidement avec l'outil Todo.txt Touch de Gina Trapani qui est la partie mobile de todo.txt. Payant mais open-source, il fonctionne bien et est maintenu par une communauté active.
De plus l'application n'a pas une structure très complexe, uniquement 2 fichiers texte dont un optionnel:

  • todo.txt: contenant l'ensemble des tâches
  • done.txt: contenant l'ensemble des tâches terminées (optionnel)
Je me retrouvais donc avec 2 fichiers synchronisés sur mes ordinateurs mais rien pour les lire de manière un peu sympa...

Après moultes recherches où j'ai trouvé des interfaces web (un peu chiant de devoir installer un apache absolument partout), des outils pour Windows uniquement ou seulement pour Linux je suis tombé sur la perle rare: QTodoTxt.

Un outil simple, multi-plateforme codé en python + Qt, open-source et rapide. Bref il semblait idéal sauf qu'il:

  • n'était plus maintenu depuis 2011
  • avait quelques bugs gênants (pas de support de l'utf8,...)
  • manquait de quelques fonctionnalités (date de création, sauvegarde automatique, auto-archivage,...)
Heureusement le code étant opensource et ayant toujours voulu jouer un peu avec du python, je me suis dis pourquoi pas, adoptons une application !

Première fois et tout se passe bien , j'ajoute des fonctionnalités, des paquets binaires, je corrige quelques bugs et j'ai même reçu mes premiers rapports de bug d'utilisateurs externes.

C'est sympa de se dire que mon application est utile à d'autres.

Du coup après 2 versions l'application permet maintenant de gérer les URLs dans les tâches, les dates de fin, la sauvegarde automatique, l'archivage automatique et la correction des quelques bugs gênants.


Même si je ne suis pas dessus en permanence je m'en sers tous les jours et elle remplie bien son but, simple,rapide et efficace!


N'hésitez pas à la tester vous aussi !

Post: 10/52

samedi 17 août 2013

Compilation de lien n°3



Ca fait longtemps que je n'ai rien publié, mille excuses !

On est reparti pour un tour avec plein de nouvelles idées et de truc sympas à découvrir. Pour le moment on va commencer doucement avec une petite collection de liens intéressants.

  • http://colorschemedesigner.com/ : Si comme moi vous galérez toujours pour trouver des couleurs qui s'accordent bien ensemble ce site est fait pour vous. À partir d’une couleur donnée et du schéma choisi (monochrome, complémentaire, triade,...), l’application déduit les différentes teintes pouvant s’accorder entre elles. Toujours pratique !
  • Nginx vient de devenir le nouveau serveur web le plus utilisé parmi les sites du Top 1000 d'après cet article de w3techs.com. Va vraiment falloir que je teste ça !
  • Twitter: un article passionnant sur l'architecture utilisée par Twitter pour gérer 150 millions d'utilisateurs.
  • Un article donnant quelques conseils pour bien réussir un entretien (on y reviendra sur ce sujet :) et pas mal de liens utiles.
  • Dernier lien mais pas des moindres, il s'agit de RunDeck, un outil permettant d'automatiser des workflows à travers une ferme de serveurs. Puppet est super sympa mais malheureusement il n'est pas possible de demander à déployer d'abord le serveur A puis le B. RunDeck permet de faire ça et bien plus encore !
Et voilà c'est tout pour le moment !

Post: 9/52

lundi 18 mars 2013

Remplacer Google Reader en 5 minutes et gratuitement


L'annonce de la part de Google de la fermeture du service Reader au 1er juillet 2013 en a perturbé plus d'un car en 7 ans d'existence Goggle Reader s'était imposé comme la solution n°1 pour consulter ses flux RSS et Atom.


Comme tout le monde je me suis mis à chercher des alternatives à Google Reader, il en existe beaucoup (Feedly, Netvibes, NewsBlur,...) mais aucune ne me convenait. Pourtant je ne demande pas grand chose:

  1. Une interface web pas trop chargée
  2. Une appli Android
  3. Une appli Android qui fonctionne en mode offline (les joies du transport en commun)
Et c'est sur le point 3. que ça bloque, je n'ai rien de trouvé de très convaincant mis à part un produit open-source Tiny tiny RSS qui se charge de tout le travail et dispose même d'un client Android gratuit et fonctionnant en mode offline, génial !

Le seul défaut et pas des moindre pour moi est qu'il faut l'installer sur son propre serveur... Pas envie de faire de l'administration de serveur le soir chez moi j'en fais déjà assez au travail, et encore moins envie de payer pour la lecture de flux RSS (je n'ai qu'une cinquantaine de flux).


Et on va faire tout ça en 3 étapes:

  1. S'inscrire à OpenShift
  2. Installer Tiny Tiny RSS
  3. Utiliser l'application Android

Inscription à OpenShift

OpenShift est la solution de PaaS de Redhat (un peu comme Google App Engine). Le gros avantage est qu'elle dispose d'une offre gratuite pour une utilisation raisonnée et c'est de ça que l'on va profiter maintenant.
On commence d'abord par s'inscrire sur OpenShift :



On remplit les champs, on valide l'email et on arrive alors à une page demandant de créer une application. Inutile d'aller plus loin on fera tout ça automatiquement par la suite.


On passe à l'étape 2.

Installation de Tiny Tiny RSS

Installation de rhc

Pour installer notre application Tiny Tiny RSS il faut installer l'outil rhc. Voici comment faire sur Linux Ubuntu (pour les autres systèmes d'exploitation voir la page RedHat dédiée):


$ sudo apt-get install ruby-full rubygems git-core
$ sudo gem install rubygems-update
$ sudo update_rubygems
$ sudo gem install rhc
$ rhc setup


Pour la dernière commande il faudra entrer le nom d'utilisateur (l'adresse mail) et le mot de passe choisit lors de la première étape.

Création de notre application Tiny Tiny RSS

On va ensuite utiliser la commande rhc pour créer automatiquement notre application grâce au travail de who-me :


$ rhc app create <app name> php-5 postgresql-8 \
--from-code=git://github.com/who-me/ttrss-fast-deployment.git
$ rhc cartridge add cron-1.4 -a <app name>


Et voilà l'installation de Tiny Tiny RSS est terminée et on peut se connecter à notre application à l'url http://<app name>-<your namespace>.rhcloud.com :





Le couple nom d'utilisateur / mot de passe par défaut est admin / password (à changer immédiatement bien sûr...).

Configuration

Nous avons notre application de gestion des flux RSS tout propre, toute neuve mais elle fait un peu vide quand même ! Pour la remplir nous allons exporter nos données de Google Reader. Pour cela utiliser le service Google Takeout qui vous permettra de récupérer vos données sous la forme d'une archive zip.

Le fichier qui nous intéresse dans cette archive se nomme subscriptions.xml et va nous servir à intégrer dans Tiny Tiny RSS tous nos flux RSS.

Pour cela dans Tiny Tiny RSS aller dans "Actions..." > "Preferences" > "Feeds" > "OPML" et sélectionner le fichier subscriptions.xml :





Tant que l'on est dans les préférences on va également activer les API externes pour le client Android Dans l'onglet "Preferences" au paragraphe "General" changer la ligne "Enable external API" à "Yes".


Et voilà terminé pour l'installation de l'application ! On passe à la partie Android !

Utilisation de l'application Android

Sur Google Play installer l'application nommée TTRSS-Reader de Nils Braden (ne pas prendre l'autre, elle ne fonctionne que 7 jours) et l'installer.

Au niveau des préférences de l'application entrer l'url de votre serveur (http://<app name>-<your namespace>.rhcloud.com normalement), le nom d'utilisateur et le mot de passe. N'activer pas le mode "Lazy Server" j'ai eu des problèmes avec. De même ne mettez pas de quote (') dans le mot de passe cela semble poser problème.


Et voilà vous avez un client Android qui fonctionne en mode déconnecté:





Bon, je l'admet les cinq minutes c'était uniquement pour appâter le chaland mais malgré tout vous voilà avec une solution viable, gratuite et qui ne s'arrêtera pas le 1 juillet !


Amusez-vous bien !


Post 8/52

samedi 9 mars 2013

Ajout d'un syntaxe highlighter à Blogger



Blogger est plutôt sympa mais il manque un truc essentiel pour un geek, un syntaxe highlighter pour que vos extraits de code ne ressemble pas à rien !

Pour ajouter ça à Blogger c'est plutôt simple, on va utiliser pour cela un script externe fait par un Googler (on reste dans la même crêmerie...): Prettify.
Prettify est composé d'un module Javascript et d'une classe CSS permettant de colorer un grand nombre de langages et cela de manière très légère. Il est égalemment modifiable via quelques styles CSS fournis (et si ça ne vous plait toujours pas le code source est disponible).
Actuellement Prettify est utilisé sur code.google.com et stackoverflow, pas mal comme références !

Installation

L'installation se déroule en une étape et on est tranquille ensuite. Il faut aller dans la partie "Modèle" de votre blog et appuyer sur le bouton "Modifier le code HTML":







Puis repérer la balise "</body>" et insérer la ligne suivante juste avant:


<script src="https://google-code-prettify.googlecode.com/svn/loader/run_prettify.js"/>


On sauvegarde et c'est terminé !

Utilisation

Utilisation Basique

Vous pouvez ensuite poster un nouveau message bien geek et lorsque vous voudrez ajouter de la coloration syntaxique il suffira d'ajouter les balises suivantes autour du contenu à modifier (en mode "HTML" bien sûr):

<pre class="prettyprint">
<?php
    echo "Hello World!"; 
?>
</pre>

Résultat:

<?php
echo "Hello World!"; 
?>

Numero de lignes

Il est possible également d'ajouter les numéros de lignes en marge du message. Pour cela il faut ajouter "linenum" à la balise pre précédente:

<pre class="prettyprint linenums">
<?php
echo "Hello World!\n";
echo "Les numéros de ligne sont affichés toutes les 5 lignes.\n";
echo "Cela peut être modifié dans la feuille de style.\n";
?>
</pre>

Résultat:

<?php
echo "Hello World!";
echo "Les numéros de ligne sont affichés toutes les 5 lignes.\n";
echo "Cela peut être modifié dans la feuille de style.\n";
?>

Spécifier un langage particulier

Prettify fait son maximum pour détecter le langage utilisé mais on peut lui faciliter la vie en précisant le langage présent entre les balises <pre>:

<pre class="prettyprint lang-dart">
library hi;

import 'dart:html';

main() {
  query('#status').text = 'Hi, Dart';
}
</pre>

Résultat:

library hi;

import 'dart:html';

main() {
  query('#status').text = 'Hi, Dart';
}


Post 7/52

Memcached: optimisation


Cet article fait partie d'une série de trois posts sur Memcached. Il fait suite au premier article: "Memcached: principe de fonctionnement" et au deuxième article: "Memcached: Gestion de la mémoire".
Troisième et dernier article sur Memcached et on finit en beauté: comment optimiser son Memcached afin de faire toujours plus avec la même quantité de mémoire !

Optimiser l'utilisation de son Memcached

Superviser son Memcached

Avant de modifier les paramètres de son Memcached il faut d'abord pouvoir les observer afin de vérifier que ce que l'on fait améliore effectivement les choses.

Pour cela deux options faciles:

  • utiliser l'interface telnet fournie afin d'obtenir des informations sur le serveur. Les informations intéressantes sont fournies par la commande "stats" et "stats slabs"
  • utiliser un script PHP affichant de manière un peu plus sympathique l'état du Memcached. Ce script est disponible sur le blog de l'auteur.






Les informations qui nous intéressent sont le compteur d'éviction (accessible uniquement via l'interface telnet) et le nombre d'éléments par slabs (via la commande "stats slabs" ou le bouton "variables" de memcached.php):





Quelques conseils

Afin de tirer le meilleur partie de Memcached il faut vérifier que:

  1. Les dates d'expiration ont été correctement paramétrées ; rien ne sert de remplir la mémoire avec des éléments inutiles. Vérifier pour cela le pourcentage de hit sur vos get memcached si celui-ci est trop bas soit vous n'avez pas assez de mémoire pour stocker tous vos éléments soit vos durées d'expiration sont trop courtes.
  2. Les données sont réparties harmonieusement au sein des slabs: si vous avez un slab qui contient 90% des éléments il peut être intéressant de partitionner plus finement ce slab en jouant sur les paramètres -n (plage de début) et -f (facteur d'augmentation). Voir à ce sujet l'exemple ci-dessous
  3. Vérifier régulièrement la taille des objets que vous stockez dans Memcached car au fur et à mesure que votre application s'étoffe il se peut que la taille des données stockées dans Memcached augmente et que les paramètres initiaux ne soient plus adaptés.
J'ai mis en pratique récemment le conseil numéro 2: il faut savoir que sur mon projet actuel nous utilisons énormément Memcached mais que les paramètres mis en place datent de plus de 4 ans et que le projet n'a plus grand chose à voir avec ce qu'il était à l'époque.
En étudiant l'un des Memcached voici ce que j'ai pu constater:

  • De nombreuses évictions (1 par seconde en moyenne)
  • 65 000 objets max stockés dans le Memcached
  • Une distribution sur les différents slabs complètement disproportionnée:



Avec -n = 8000 et -f = 2


On voit clairement sur le graphique que le premier slab contient l'immense majorité des données. Le paramètre de taille initiale du slab a été visiblement mal choisi et il faut l'affiner.
La principale conséquence de ce choix est que l'on utilise 8 kio de mémoire pour tous les objets stockés dans Memcached alors que ceux-ci font en moyenne entre 3 et 4 kio (soit 50% de mémoire perdue à chaque fois!!) ce qui implique que l'on ne peut stocker que peu d'informations.
On voit bien ici l'importance de connaître ses données afin d'optimiser au mieux les paramètres.


Nous avons donc modifié les paramètres comme suit:

  • Diminution de la taille du premier slab de 8000 octets à 1000 octets afin de mieux découper l'espace où se trouve nos données
  • Même facteur d'accroissement
  • Même mémoire allouée






Les conséquences de cette modification:

  • Peu d'évictions (Quelques centaines par jour)
  • 125 000 éléments stockés dans Memcached (pour la même quantité de mémoire allouée !!)
  • Une distribution mieux répartie
On peut se dire au vu du graphique qu'il est encore possible de faire mieux en diminuant le facteur multiplicatif afin de décomposer encore plus le slab3 en de multiples slabs. Cette solution n'a pas été retenue car nous souhaitions garder une relative flexibilité dans la taille de nos données qui sont amenées à bouger régulièrement et donc nous focaliser sur la tranche 3 à 4 kio nous semblait trop réducteur pour les développements futurs de l'application.


C'est ainsi que se termine cette série de trois articles sur Memcached un outil fantastique pour améliorer les performances et la scalabilité de votre application.




Quelques liens intéressants:

Post 6/52

vendredi 8 mars 2013

Memcached: Gestion de la mémoire


Cet article fait partie d'une série de trois posts sur Memcached. Il fait suite au premier article: "Memcached: principe de fonctionnement"

Deuxième article sur Memcached et on passe aux choses sérieuses, la gestion de la mémoire par Memcached !


Gestion de la mémoire par Memcached

Expiration

En fonctionnement nominal la mémoire utilisée par les éléments expirés dans Memcached n'est pas réclamée activement. Ainsi même si l'élément est expiré alors sa mémoire ne sera pas libérée immédiatement.
Un cas particulier arrive quand on essaye de récupérer un élément expiré. Dans ce cas Memcached va se rendre compte que l'élément est expiré et libérer immédiatement la mémoire utilisée.

Insertion d'un élément dans le cache

Lorsque l'on ajoute un nouvel élément dans Memcached celui-ci vérifie un certain nombre de choses:

  • Étape 1: Reste-t-il de la place dans la page courante ?
  • Étape 2: Reste-t-il des pages mémoires non allouée à un slab ?
  • Étape 3: Déclenchement de l'algorithme LRU

Étape 1 : affectation simple

 

Cette étape est la plus simple et la plus classique: s'il reste de l'espace dans la page courante alors on utilise un chunk de cette page pour stocker notre élément.
Rien de bien compliqué ici !


Étape 2 : assignation d'une page

 

Nous arrivons dans cette étape s'il n'y a plus de chunk libre dans la page courante. A ce moment Memcached vérifie s'il lui reste des pages mémoire de 1 Mio non affectée au slab courant et si c'est le cas alors il assigne une plage libre au slab courant.
En faisant cela il découpe également cette page en chunk de même taille et utilise un de ces chunk pour stocker l'élément à insérer.


Attention : une fois qu'une page est assignée à un slab cette page ne peut plus être affectée à un autre slab.


Étape 3 : LRU et éviction

 

S'il n'y a plus de chunk ni de page disponibles alors Memcached va commencer à libérer de l'espace en utilisant un algorithme de type LRU (Least Recently Used). Le principe de cet algorithme est de maintenir une liste d'éléments par date d'utilisation. Ainsi un élément peu utilisé apparaîtra dès le début de cette liste. Memcached va alors parcourir les premiers éléments de la liste et libérer l'espace utilisé par un élément expiré.


La particularité de Memcached est qu'il ne maintient pas une liste globale listant l'ensemble des éléments mais une liste par slab. Ainsi l'algorithme LRU n'est pas global mais local par slab. Memcached conserve une liste d'éléments par slab:




Ainsi dans le scénario 1 l'algorithme LRU va parcourir le début de liste et supprimer l'élément 2 car il est expiré. Dans le scénario 2 au contraire il n'y a pas d'élément expiré dans les premiers éléments de la liste, Memcached va alors "évincer" le premier élément même si celui-ci n'est pas encore expiré. Cette action se nomme une eviction.


Habituellement on n'aime pas trop les évictions car elles correspondent à la suppression d'un élément encore valide dans Memcached. Néanmoins sur certains environnements où la mémoire est limitée ou la quantité d'éléments à stocker est très important il est intéressant de s'appuyer sur ce mécanisme pour conserver dans le Memcached les éléments les plus couramment utilisés et supprimer les autres.


Ce mécanisme fonctionne bien en général mais il peut arriver que malgré tout Memcached manque de mémoire et soit incapable d'en retrouver:
Supposons que l'on dispose de 3 slabs : slab1, slab2 et slab3.
Au démarrage du processus memcached tous les éléments sont insérés dans le slab1 et le slab3 et toute la mémoire allouée à Memcached est utilisée. A ce moment si l'on insère un nouvel élément dans le slab1 ou le slab3 le mécanisme de LRU va se déclencher pour libérer de la mémoire et donc stocker notre élément.






Mais imaginons que l'on souhaite insérer un élément dont la taille le destine à être stocké dans le slab2. Comme il n'est pas possible de réaffecter une page à un autre slab, nous ne pourrons jamais insérer notre nouvel élément dans Memcached et une erreur est renvoyée:




Cette exemple montre bien qu'il est primordial de bien configurer son serveur Memcached afin d'en tirer le maximum. C'est ce que nous allons voir dans la troisième et dernière partie: "Memcached: optimisation".

Posts  5/52