Entries in the Category “francais”

PyCon Fr 2010

written by ccomb, on Sep 1, 2010 12:34:00 PM.

PyCon Fr 2010

Le week-end dernier avait lieu PyCon FR, la rencontre annuelle sur Python en France, organisée depuis 4 ans par l'afpy et qui consiste en 2 jours de conférences et ateliers à la Cité des Sciences.

Voici un petit résumé de l'événement.

Fréquentation

On partait avec deux gros handicaps : la date, fin août, ne garantissait pas que tout le monde soit rentré de vacances. De plus la communication n'a pas été très bonne. Malgré tout, dès le samedi matin la salle (L'Agora du Carrefour numérique) était quasi pleine, et la fréquentation n'a pas baissé jusqu'au dimanche 18h, où les gens n'avaient manifestement pas envie de partir. Un petit sondage le dimanche matin a montré qu'une majorité de visiteurs s'était déplacé de province.

L'événement a été soutenu par 10 sponsors, qu'on remercie une nouvelle fois :

Tout a été enregistré par Ubicast et sera disponible en ligne. Le site web a été géré par Logilab, grâce à Cubicweb.

Tendances

Python

Le Web : le développement web est comme toujours un sujet majeur en Python. Serveur WSGI haute performance, CMS orienté sémantique, CMS sur mesure, CMS qui stocke en Git, nombreux frameworks web, cloud computing, réseau social distribué, le sujet était vaste.

Calcul scientifique : deux conférences passionnantes sur le Machine Learning, le traitement des langues naturelles, l'analyse statistique, le calcul parallèle ou le multiprocessing, l'interfaçage avec C/C++.

Cloud et NoSQL : Une confirmation de la tendance de l'année dernière, avec des présentations parlant de MongoDB, itools.database (une DB versionnée), Google App Engine, SilverLining, MediaTemple, LibCloud, etc...

ERP : Une présentation de Tryton, un fork d'OpenERP, fait aussi par des belges, qui proposent également une version allégée minimale (Neso). La demande pour OpenERP est, paraît-il, monumentale.

On a regretté l'absence de Tarek Ziadé, obligé de rentrer d'urgence à Dijon, et qui aurait dû présenter son travail chez Mozilla : la réécriture de Mozilla Sync en Python. On a regretté aussi l'annulation de dernière minute d'une présentation sur Plone.

OSDC Fr 2010

En parlant de Plone, je serai à OSDC Fr les 9 et 10 octobre pour parler de Plone 4 qui vient de sortir, ainsi que d'une application permettant de déployer des démos d'applications web (Drupal, Plone, OpenERP, etc...).

Debian, Ubuntu, dedibox v3 : deuxième round

written by ccomb, on Aug 17, 2010 1:56:00 AM.

Influence de l'ext4 sur les performances

Debian

Un peu étonné des résultats d'avant-hier montrant Ubuntu largement à la traine par rapport à Debian, j'ai voulu vérifier les résultats en utilisant cette fois la même dedibox v3. J'ai donc relancé une fois le benchmark en Ubuntu 10.04 64bits, puis je l'ai réinstallée complètement en ext4 (dispo depuis peu à l'install dedibox).

L'apport de l'ext4 est ici nettement visible en écriture. Sinon les résultats sont assez proches.

/static/bench3/read.png /static/bench3/random_read.png /static/bench3/write.png
/static/bench3/random_write.png

Debian vainqueur par K.O.

J'ai ensuite réinstallé avec la Debian 5.0 Lenny proposé aussi par dedibox. Et là on retrouve bien la même différence qu'avant-hier, que je trouve énorme. Je n'ai pas encore eu le temps de creuser, il s'agit sûrement d'un réglage lors du montage, de la journalisation, du scheduler ou je ne sais quoi d'autre. En tout cas pour une installation par défaut c'est regrettable.

/static/bench5/read.png /static/bench5/random_read.png /static/bench5/write.png
/static/bench5/random_write.png

Vous me direz, oui, mais l'Ubuntu peut être installée directement en ext4, qui améliore pas mal. Qu'à cela ne tienne, comparons donc la vieille Debian 5.0 ext3 et la nouvelle Ubuntu 10.04 ext4. Là encore, la Debian est plus rapide, sauf en écriture pour les gros fichiers :

/static/bench6/read.png /static/bench6/random_read.png /static/bench6/write.png
/static/bench6/random_write.png

Et la prochaine Debian 6.0 ?

Pour finir, j'ai effectué la mise à jour en Debian 6.0 Squeeze, qui vient juste d'être gelée. Pour mémoire, l'upgrade en Debian 6.0 se déroule en gros comme ceci :

  • remplacer lenny par squeeze dans /etc/apt.sources.list
  • # aptitude update
  • # aptitude install apt aptitude dpkg
  • # aptitude full-upgrade
  • # upgrade-from-grub-legacy
  • # aptitude install linux-image-2.6-amd64
  • remplacer GRUB_DEFAULT=0 par GRUB_DEFAULT=2 dans /etc/default/grub
  • # upgrade-grub
  • # reboot
  • # aptitude remove --purge linux-image-2.6.32-bpo.4-amd64
  • Remettre GRUB_DEFAULT=0 dans /etc/default/grub
  • # upgrade-grub

Debian 5.0 et Debian 6.0 sont très proches, même si on note un léger avantage à la nouvelle version :

/static/bench7/read.png /static/bench7/random_read.png /static/bench7/write.png
/static/bench7/random_write.png

Et Debian 6.0 en ext4 ??

Ah mais vous voulez vraiment le beurre et l'argent du beurre... Bon ok. On lance le système de secours Dedibox, puis :

  • # sudo tune2fs -O extents,uninit_bg,dir_index /dev/sda1
  • # sudo tune2fs -O extents,uninit_bg,dir_index /dev/sda2
  • # sudo e2fsck -fDC0 /dev/sda1
  • # sudo e2fsck -fDC0 /dev/sda2
  • Puis remplacer ext3 par ext4 dans /etc/fstab.
  • Par précaution j'ai aussi fait un update-grub après avoir chrooté la racine, puis monté /boot, /proc et /sys, mais je pense que c'était inutile.

Ensuite on redémarre, et voici ce que ça donne. Comme pour l'Ubuntu, le système de fichiers ext4 améliore surtout les performances en écriture. Mais l'amélioration est encore plus spectaculaire, car on gagne ici 70% au lieu de 60% (sur la moyenne) dans le cas de l'Ubuntu :

/static/bench8/read.png /static/bench8/random_read.png /static/bench8/write.png
/static/bench8/random_write.png

La conclusion, c'est que Debian fait toujours du bon boulot... Je ne pense pas que le problème vienne spécialement des Dedibox, car je retrouve la même forme sur mon portable en Ubuntu 64bits ext4.

Comparatif entre les disques durs Dedibox v1, v2, v3 :

Lors des tests précédents j'ai lancé simplement iozone -a, qui utilise les buffers du noyau lors des transferts. C'est pour cette raison qu'on obtient des taux énormes, de l'ordre de 1 ou 2 Go/s. C'est un bon test en conditions réelles car il fait intervenir aussi le CPU. Si on recommence la même chose en lançant plutôt iozone -aI, on obtient le taux de transfert réel du disque dur, plus utile pour tester vraiment le matériel. C'est le même genre de différence qu'entre hdparm -t et hdparm -T. Voici donc la comparaison entre les trois dedibox. Pour la dedibox v1 j'ai limité le nombre de tests, faudrait pas la fatiguer, ni qu'elle meure avant la migration... :)

La surprise, c'est que le disque le plus lent est celui de la dedibox v2. Quant à la v3, elle reste encore la plus rapide. J'ai aussi effectué le test en ext4, et là encore on note une belle amélioration des performances grâce à l'ext4.

/static/bench4/read.png /static/bench4/random_read.png /static/bench4/write.png
/static/bench4/random_write.png