dimanche 12 mai 2013

Une épingle à nourrice

Voici la modélisation et le rendu d'une épingle à nourrice. Finalement, ça a été plus simple que ce que je pensais. L'épingle a été modélisée en utilisant un chemin Nurbs, comme montré sur l'image en dessous, et un cercle Nurbs utilisé comme bevel object. J'ai utilisé une photo d'épingle en fond afin de me calquer dessus.

Gérer le ressort proprement a été un peu compliqué, puisqu'il a fallu remonter d'un côté et redescendre de l'autre pour ne pas que la boucle rentre en elle-même. Finalement, tout a été fait au pifomètre, et ça ne marche pas trop mal.

Pour la partie qui coince l'épingle, j'ai suivi la bonne vieille méthode de démarrer avec un cube, d'extruder vaguement pour couvrir la forme, et d'appliquer la modification sub-surface jusqu'à ce que ça ressemble à quelque chose.

Et pour finir, un rendu avec fond transparent dans un angle qui cache les parties moches, et basta!

mercredi 8 mai 2013

async_commit=off

J'expérimente ces temps-ci avec l'option "async_commit=off" de Postgresql. Cette option indique au serveur de rendre la main au client dès que le commit est effectué en mémoire, sans attendre que les données soient effectivement écrites sur le disque. L intérêt est donc de découpler la vitesse d'écriture sur le disque dur, et donc de diminuer la latence et d'augmenter le nombre de transactions par seconde.

En contrepartie, si le serveur venait à crasher, quelques secondes de données seraient perdues. Si cette contrainte est acceptable, par exemple parce que les données sont mises à jour régulièrement, ou parce que plusieurs bases tournent derrière un pgPool, c'est un sacré coup de boost.

Voici un petit benchmark qui fait tourner en boucle 1000 transactions, chaque transaction insérant un entier dans une table faite d'une simple colonne, sans contraintes. Le test tourne en local et en distant sur une machine avec lequel j'ai un ping de 200ms, avec synchronous_commit=off et synchronous_commit=on.

L'on voit que les performances augmentent d'environ 30% en local, ce qui est tout à fait appréciable. Mais l'autre chiffre intéressant est la grosse chute de performances en distant: le gain du commit asynchrone reste à peu près identique en relatif, mais la chute est rude. Le fait d'avoir à faire l'aller-retour pour chaque transaction est très coûteux.

La conclusion, c'est que s'il est possible de relâcher ses contraintes d'intégrité, synchronous_commit=off est une manière simple d'obtenir un impressionnant gain de performances. Mais c'est aussi que dans le cas de nombreuses petites transactions, le goulot d'étranglement se trouve sur le réseau, et non sur le disque ou le processeur. Dans ce cas, peut-on imaginer de faire tourner une base en local pour les performances, qui se répliquerait de manière asynchrone sur une base distante utilisée pour le basculement lors d'un crash?