J'ai eu par le passé à effectuer des tests de charge sur des serveurs de tuiles comme ceux mis en oeuvre sur le projet OpenStreetMap. Afin d'assurer des requêtes aléatoires sur tous les niveaux de zoom j'avais écrit à l'époque un plugin pour Tsung que je n'avais pas encore pris le temps de publier, voilà qui est chose faite.

Le plugin se nomme wmsosm.erl et est publié sur github en licence GPLv3. Il permet de générer la partie finale de l'url en z/x/y afin de pouvoir l'intégrer dans la balise request du scénario Tsung. L'utilisation se fait en appelant la fonction urlzxy du module wmsosm, voir l'exemple ci-dessous. Le détail de la mise en oeuvre d'un plugin Tsung est décrit dans la [documentation du projet| http://tsung.erlang-projects.org/user_manual.html] je ne m'étendrais pas sur le sujet.

<request subst="true">
  <http url='/%%wmsosm:urlzxy%%.png' version='1.1' method='GET'></http>
</request>

Le choix de la tuile dans un niveau de zoom donné est aléatoire. le choix du niveau de zoom est aléatoire mais avec pondération, le choix est fait de telle sorte que les niveaus de zooms élevés sortent plus souvent, techniquement le tirage est fait dans une liste qui contient 2 fois le zoom 2, 3 fois le zoom 3 et ainsi de suite.

Ci-dessous un exemple d'un extrait d'utilisation du plugin

"GET /7/88/93.png HTTP/1.1"
"GET /16/17017/19589.png HTTP/1.1"
"GET /11/1791/1872.png HTTP/1.1"
"GET /17/47098/51507.png HTTP/1.1"
"GET /17/40683/45092.png HTTP/1.1"
"GET /17/47025/51434.png HTTP/1.1"
"GET /17/38091/42500.png HTTP/1.1"
"GET /3/4/4.png HTTP/1.1"
"GET /10/839/874.png HTTP/1.1"
"GET /15/6096/7382.png HTTP/1.1"
"GET /18/114432/123250.png HTTP/1.1"
"GET /18/139028/149316.png HTTP/1.1"
"GET /3/4/4.png HTTP/1.1"
"GET /16/17609/19814.png HTTP/1.1"
"GET /12/39/200.png HTTP/1.1"
"GET /18/129410/138228.png HTTP/1.1"
"GET /18/117680/126498.png HTTP/1.1"
"GET /4/9/9.png HTTP/1.1"
"GET /10/836/865.png HTTP/1.1"
"GET /6/40/42.png HTTP/1.1"

Je travaille sur une version améliorée du plugin afin de tirer des blocs aléatoires de tuiles plutôt que des tuiles uniques, ce qui se rapprochera plus des cas réels d'utilisation. On déterminera de façon aléatoire une première tuile et des requêtes seront générées de façon ordonnées dans un ensemble de tuiles voisines paramétrable.