S'abonner au Flux RSS

lundi, août 10 2015

Utiliser pg_shard avec Django

L'hiver dernier CitusData à ouvert le code source de son outil de partitionnement pg_shard, le code est désormais publié sous licence LGPL version 3, et disponible sur github. Le 30 juillet dernier la version 1.2 a été releasé, ce fut l'occasion pour moi de tester la compatibilité de Django avec cette nouvelle extension PostgreSQL.

Pour rappel le sharding permet de distribuer le contenu d'une table sur plusieurs serveurs, pg_shard permet également de gérer de multiples copies d'un même réplicats afin de palier à une éventulle faille sur l'un des noeuds. L'intérêt principal du sharding est de pouvoir garantir la scalabilité quand le volume de données augmente rapidement, l'accés aux données se faisant toujours sur le noeud principal sans avoir à prendre en compte les noeuds secondaires qui sont trasparents pour le client.

Autant le dire tout de suite, et ne pas laisser le suspens s'installer, Django n'est pas compatible avec pg_shard, cela pour trois raisons principales détaillée ci-dessous. D'auutres points sont peut-être bloquant, mais je n'ai pas introspecté plus en avant après avoir déjà constaté ces premiers points de blocage.

Lors de la sauvegarde d'un nouvel objet dans la base Django utilise la clause RETURNING dans l'INSERT afin de récupérer l'id de l'objet. A ce jour pg_shard ne supporte pas RETURNING, un ticket est en cours, espérons qu'une future version soit publiée avec cette fonctionnalité.

Plus problématique car cela demanderai un hack un peu plus profond dans l'ORM de Django, le non support des séquences qui sont utilisées par le type SERIAL afin de bénéficier de la numérotation automatique et unique des clés primaires. C'est ce type qui est utilisé par défaut par Django pour les pk. Là encore des discussions sont en cours pour supporter les sequences dans pg_shard.

Enfin et c'est peut-être ce qui serait le plus bloquant pour une utilisation avec Django ou un autre ORM, pg_shard ne supporte pas les transactions multi-requêtes. Les transactions étant la base de la garantie de l'intégrité des données ; à part être dans un cas d'usage où l'on ne modifie pas plus d'une donnée à la fois, cela peut être une raison pour ne pas adopter pg_shard dans l'état.

Malgré ces constats pg_shard reste une solution très intéressante, qu'il faut garder dans un coin de sa veille techno, à l'époque où le big data revient si souvent dans les conversations autour de la machine à café.

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 !

mercredi, mars 25 2015

PgDay Paris

J'ai la plaisir cette année de participer au comité de sélection du PgDay Paris qui se déroulera le 21 Avril 2015.

Le pgDay Paris est une journée de conférences et d'échanges organisée par la communauté française de PostgreSQL. Un ensemble de présentations en anglais et en français sera proposé, couvrant des sujets techniques ainsi que des retours d'expérience d'utilisation de PostgreSQL en production.

Que vous soyez développeur, administrateur système ou de bases de données ou bien « décideur » (DSI, directeur technique, etc), nous aurons du contenu pour vous !

Les inscriptions à l'événement sont dès maintenant disponibles pour le prix de 65 € pour la journée, qui inclut les pauses cafés et le déjeuner complet sur place.

Les places étant limitées, je vous invite à vous inscrire au plus tôt afin d'être sûr de pouvoir venir.

  • https://www.postgresql.eu/events/register/pgdayparis2015/

Le prix des places est maintenu volontairement bas afin de permettre au plus grand nombre de participer. Cela est rendu possible grâce au soutien des sponsors, et il reste là aussi des places. Alors si vous souhaitez apporter votre contribution au développement de PostgreSQL n'hésitez pas à prendre contact, toutes les coordonnées sont sur le site de l'évènement.

Rendez-vous le 21 !

dimanche, mars 22 2015

De retour de Confoo

J'ai eu la chance cette année de donner deux conférences à ConFoo qui c'est déroulé mi-frévier à Montréal, je m'étais promis dans l'avion de rédiger un billet sur cette expérience, et je trouve enfin le temps de le faire près d'un mois et demi après. Anyway, il est toujours temps de dire que j'ai été assez bluffé par l'organisation parfaite de cet évènement, en toute honnêteté je ne vois rien à redire ; il y a toujours des hics et des couacs dans tout évènement, ici même en cherchant bien impossible de citer un problème ou un dysfonctionnement. Quand on a connu des conférences où l'on devait venir avec sa propre bouteille d'eau et où les organisateurs n'avaient pas dénier offrir un café, ça change ! Et quand on vient présenter un sujet c'est vraiment très appéciable de sentir que tout roule et que l'on ne sera pas obligé de courir au troisième sous-sol pour trouver un projecteur qui fonctionne. J'ai été particulièrement impressionné par l'équipe de bénévole d'une redoutable efficacité, reçevoir dans les 30 minutes les fiches retour d'avis des participants dans sa boîte mail, cela frôle la perfection, chapeaux les artistes !

Bien sûr présentant des sujets peut-être un peu borderline je n'ai pas eu à souffrir d'une affluence à faire fermer les portes en avances. On sent un poids historique des conférences tout PHP des premières années, néanmoins l'ouverture est là et à encourager et je suis persuadé que le temps donnera raison aux organisateurs de s'ouvrir aux autres technologies.

Pour ma part ma première présentation sur Django et PostgreSQL sour la charge a certes reçu un accueil limité, mais les petites salles ont l'avantage de permettre de vrais échanges et cela a été un plaisir pour moi de faire découvrir quelques astuces de Django aux participants.

J'avais remanié ma désormais classique conférence sur Tsung de 1 à 1 million qui s'est déroulée avec un public plus fournit que la veille, les échanges post présentation ayant dûs se prolonger à l'extérieur.

Une vraie belle expérience que je vous invite à vivre tous !

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.

vendredi, mai 16 2014

Plugin Typeahead pour Tsung

Lors de ma participation au code sprint sur le projet de geocoder pour OpenStreetMap photon il est apparu rapidement qu'un des enjeux en terme de performance résidera dans la volonté de retourner des résultats lors de la saisie au fil de l'eau dans le formulaire de recherche. Ce que l'on appelle dans nos vilains anglicisme le typeahead et rendu populaire par typeahead.js en autres.

Lire la suite...

mardi, mai 13 2014

Module puppet pour Tsung

Lors d'un déploiement d'un cluster Tsung tous les noeuds doivent être dans la même version, si le packaging inclus dans les distributions classiques comme Debian, Ubuntu ou Fedora permet de satisfaire simplement cette contrainte pour les versions stables et packagées, il n'en est pas de même pour une utilisation de la version instable ou en cours de développement.

Lire la suite...

mercredi, mai 7 2014

Monitorer OSRM

Avoir une application en production implique d'en assurer un monitoring de suivi afin de savoir si tout est au vert, cela permet de s'y mettre quand on a un système de qualité. Mais passons ces considérations philosogeek et revenons au sujet du jour à savoir le monitoring d'une instance OSRM, pour ma part j'utilise Nagios depuis de longues années et en suis toujours assez satisfait. J'ai pris un peu de temps ces derniers jours pour publier ma configuration sur le dépôt nagios-plugins-osrm.

Les appels API de base utilisent la fonction standard check_http cela permet de savoir si le service est up, mais sans analyse de la réponse.

En utilisant check_osrm_viaroute_result qui nécessite un check non standard (voir le README du dépôt) vous avez non seulement un retour sur le bon fonctionnement du service mais également sur les données retournée. Dans ce cas vous savez si OSRM trouve une route entre les deux points de coordonnées.

Dans la suite de cette publiucation je vais également prochainement publier mes sondes pour Nominatim.

mardi, mars 11 2014

Debian, PG9.3, Osmosis et Nominatim

Même en se basant sur des références en terme de stabilité il peut arriver que certains combos soient fatals à votre production. C'est ce qui m'est arrivé récemment pour un serveur Nominatim installé pourtant sur une Debian Wheezy, osmosis est utilisé pour la mise à jour continue de la base Nominatim et m'a fait des misères que je m'en vais vous conter.

Lire la suite...

jeudi, mars 6 2014

rosarks.eu

Je profite d'avoir la chance de pouvoir ré-écrire Lolix from scratch pour penser aux fonctionnalités qu'il m'aurait plu d'avoir quand je cherchais un travail, sur ce point j'ai toujours été surpris de voir à quel point les entreprises font bien peu d'effort pour aider les candidats à trouver leur locaux. Peut-être que les recruteurs imaginent que tout le monde sait où se trouve leur bureau, ou parce qu'ils imaginent cela comme une première épreuve pour mesurer le niveau de débrouilliardise du candidat, en tout état de cause personnellement je trouve qu'indiquer la sation de bus/tram/métro/vélocation à proximité ne peut être qu'un plus sur une offre d'emploi.

Lire la suite...

- page 1 de 13