Une fonctionnalité aussi intéressante que puissante de Tsung est de permetre de générer des paramètres ou des urls depuis des modules externes écrits en erlang. La documentation (1) officielle indique que les modules doivent être déployés dans le répertoire ebin de Tsung qui est généralement un répertoire système non accessible en écriture aux utilisateurs non privilégiés. Il existe une méthode alternative pour ceux qui ne possèdent pas les permissions root sur leurs machines, cela consiste à indiquer le chemin des librairies au niveau erlang en déclarant la variable ERL_LIBS qui contiendra le nom du répertoire contenant vos modules. Les fichiers .beam seront copiés dans un répertoire nommé obligatoirement ebin qui sera placé dans le répertoire indiqué dans ERL_LIBS. A noter que l'on peut indiquer plusieurs répertoires en les séparant par des virgules comme souvent pour les PATH.

Exemple :

ERL_LIBS=/home/rodo/modules

Les fichiers .beam seront dans

/home/rodo/modules/ebin/

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.

Si il est intéressant d'utiliser un ORM pour manipuler des objets dans une base de données relationnelle il présente également inconvénient de cacher les requêtes réellement exécutées sur la base de données. Tous les frameworks de développement n'intègre pas forcément de moyen simple d'avoir accés aux requêtes, Django permet de faire cela à partir d'extension comme django-devserver (1[https://github.com/dcramer/django...) ou d'autres ; extensions qui sont utilisables en développement ou sur des machines de pre-prod, mais malheureusement pas en production. Disons que l'on ne s'intéressera pas ici aux sites qui utilisent runserver sur leur serveur de prod, humm.

Résumons le contexte on a une application Django en production et on a besoin de récupérer l'intégralité des commandes SQL passées lors d'une opération de bench.

On va pouvoir faire cela simplement car Django intégre de base un (logger) nommé django.db qui va nous permettre de le faire. On va logger toutes les requêtes directement dans un fichier en configurant dans les settings un handler sur un fichier et en utilisant le logger djangodb.

En pratique on ajoute une entrée file dans la section handlers

    'handlers': {
        'mail_admins': {
            'level': 'ERROR',
            'filters': ['require_debug_false'],
            'class': 'django.utils.log.AdminEmailHandler'
        },
        'file': {
            'level': 'DEBUG',
            'class': 'logging.FileHandler',
            'filename': '/tmp/django-sql.log',
        },
    },

et une entrée django.db dans la section loggers qui utilise l'entrée file

    'loggers': {
        'django.request': {
            'handlers': ['mail_admins'],
            'level': 'ERROR',
            'propagate': True,
        },
        'django.db': {
            'handlers': ['file'],
            'level': 'DEBUG',
            'propagate': True,
            }
    }

On aura toutes nos requêtes sql dans le fichier /tmp/django-sql.log sous la forme

(0.000) SELECT "graph_dashitem"."id", "graph_dashitem"."dash_id", "graph_dashitem"."graph_id", "graph_dashitem"."order" FROM "graph_dashitem" WHERE "graph_dashitem"."dash_id" = 2 ORDER BY "graph_dashitem"."order" ASC; args=(2,)

Le premier champs contient le temps d'exécution et le dernier la liste d'arguments, on obtient un fichier facilement parsable dans lequel on pourra rechercher les requêtes gourmandes en temps par exemple. La prochaine étape sera de passer les requêtes dans EXPLAIN pour les analyser.

Avertissement si votre site a un fort traffic le log de toutes les requêtes va générer beaucoup de consommation d'IO, et d'espace disque, pensez à désactiver les logs quand vous avez finit votre bench.

La partie majeure du travail lors d'un opération de test de montée en charge d'un site web est l'analyse des résultats, afin de simplifier cette partie je travaille actuellement sur un outil d'aggrégation de données qui regroupera les données systèmes et les logs générés lors d'un benchmark de site web opéré avec tsung (1). Le développement de la première version de cet outil est basé sur graphite (2) qui sera utilisé pour la génération des graphiques. N'existant pas à ma connaissance d'outil permettant de pousser dans graphite les données recueillies par tsung lors d'une opération de bench j'ai commencé l'écriture d'un script python pour effectuer cette opération. Suivant le précepte du 'release early, release often' j'ai publié le script sur la plateforme gitorious afin de le rendre disponible de suite, il est publié sous licence GPL v3.

Le script est actuellement en version 0.2.0 avec les fonctions de base, je l'utilise déjà en production.

• Page projet : https://gitorious.org/tsung2graphit...
• Bugtrack : http://redmine.quiedeville.org/proj...

Si j'aime les virtualenv quand je code je reste attachés aux paquets pour le déploiement et j'essaye tant que faire se peut de résister aux 'pip install -r requirements.txt' sur mes machines de production. C'est dans ce contexte que j'ai packagé quelques paquets relatifs à Django que je vais essayer de maintenir au sein du projet Pyrede.

http://pyrede.quiedeville.org/debian/

Le fichier repo.key contient la signature utilisée pour signer les paquets.