S'abonner au Flux RSS

Mot-clé - performance

Fil des billets - Fil des commentaires

mercredi, août 5 2015

pgBouncer dans un contexte Django

PgBouncer est un gestionnaire de pool de connexion pour PostgreSQL très efficace, il permet de réduire drastiquement le temps de connexion à la base depuis votre client.

Dans un contexte d'utilisation avec Django l'intérêt peut ne pas apparaître de suite, le temps passé dans l'exécution et la récupération de la requête étant souvent bien supérieur au temps de connexion. Ce paradigme tend à s'inverser dans un contexte d'API ; j'ai eu récemment l'occasion de mesurer l'impact de son utilisation sur un cas réel suite à un problème de timeout sur une API.

L'API est consommée à des taux certes raisonnables, autour de 25 appels par secondes, mais l'accroissement régulier faisait apparaitre des TIMEOUT de plus en plus souvent au niveau du client. En frontal les appels sont reçus par Nginx qui renvoit ceux-ci à des process gunicorn, le timeout coté Nginx est de 60 secondes, c'est ce timeout qui se déclenche. Les mesures sur l'infra de tests de performances continus montraient des temps de réponses de l'ordre de 120msec sous faible charge, ce qui n'était pas cohérent avec les 60 sec du timeout de Nginx.

Seulement après une revue complète de l'infrastucture du SI il est apparu que sur l'environnement de test pgbouncer était installé et correctement configuré, alors que cela n'était le cas du coté de la production. J'ai alors mené une série de tests avec et sans pgbouncer sur la même architecture, afin de mesurer son impacte réel ; PgBouncer faisant partie des préconisations initiales que j'avais faite sur ce projet.

Le test effectue un appel simple avec des données aléatoire et injecte un nombre croissant d'utilisateur pour arriver au plateau de 60 users/sec; il a été mené avec Gatling.

Les premiers tests avec pgbouncer donnent des temps de réponses médians de 285ms avec un 99th percentile à 1650ms, toutes les requêtes sont traitées avec succès

with-pgbouncer.png

Si on débranche pgbouncer le temps de réponses médian croit à 14487ms et surtout le max dépasse 60126ms ce qui donne un nombre croissant de requête en timeout sur la fin du test quand on arrive à pleine charge.

without-pgbouncer.png

Sur la plateforme de test PgBouncer est installé sur la machine qui fait tourner les process gunicorn, le configuration de Django est donc positionnée sur le loopback. La base de données PostgreSQL est elle sur une machine distante avec une connexion sur le LAN.

PgBouncer peut apparaître comme un outil compliqué quand on a pas l'habitude des bases de données, mais il est fort à parier que votre DBA le connait déjà, alors si l'utilisation de vos API croît ayez le réflex PgBouncer !

lundi, septembre 22 2014

Django Paginator oui mais

Après la lecture de l'excellent article de Markus Winnand no-offset j'ai réalisé un test pour mesurer la différence de performance de l'utilisation d'OFFSET avec Django.

La suite à lire sur le blog Novapost's paradize.

mardi, février 4 2014

Montée en charge de Wordpress

Dans la famille des tests de performance, le test de montée en charge consiste à tester un système avec un volume de données croissant afin de déterminer son comportement dans le temps, il est parfois aussi appelé test de vieillissement mais quelque soit son nom il a pour but de rassurer l'utilisateur sur l'utilisation à venir d'un outil. Tout ceux qui ont fait du développement et de l'exploitation de système d'information comportant une base de données savent bien ce qu'implique une augmentation du volume de donnée traité. Un index mal placé ou non utilisé et les temps de réponses croissent au fil des jours pour arriver parfois à un blocage complet du système. Il est pourtant simple de se protéger de cela en effectuant en pré-production des tests de montée en charge afin de mesurer les temps de réponse en fonction du volume de donnée dans le système.

Lire la suite...

mardi, octobre 15 2013

Inscription ouverte pour Nantes

Comme annoncé dans un précédent billet je ferai une présentation de Tsung intitulée de 1 à 1 million, mesure de la performance web avec Tsung mardi 22 octobre à la cantine de Nantes, la page d'inscription est désormais en ligne. La participation est libre et gratuite et le thème abordé est accessible à tous, développeur, devOps et chef de projet.