Mathieu Agopian : Latence et boucle de rétroaction

Latence

La latence en informatique est un délai minimum de transmission. C'est un des principaux ennemis de la performance notamment dans le domaine du web.

Un site web est généralement composé de multiples fichiers statiques (css, javascript, images et icônes en tout genre). Pour afficher la totalité d'une page, il faut donc faire de multiples requêtes au serveur, chacune prenant un certain temps de traitement, à quoi on rajoute la latence (le temps de transfert sur le réseau).

On imagine facilement l'impact d'une forte latence lorsqu'il faut effectuer plusieurs dizaines voire centaines de requêtes. Même si la latence n'est que de 10ms, si on multiple ça par 100, on atteint déjà une seconde.

Prenons un autre exemple : il n'est pas rare d'avoir des pages nécessitant des dizaines (des centaines, voire des milliers ?) de requêtes SQL à une base de données. Là encore, il faut multiplier ce nombre de requête par le temps de traitement par la base de données, mais aussi par la latence.

Étant donné la difficulté de réduire la latence, l'optimisation de la performance passe par le réduction du nombre de requêtes : on fait des bundles pour les fichiers statiques (on regroupe toutes les CSS ou les fichiers javascript, on crée des image map pour les icônes), on fait usage du JOIN pour les requêtes SQL...

Boucle de rétroaction

La boucle de rétroaction (appelée « feedback loop » en anglais) permet de raffiner un système afin d'arriver à un équilibre, à un objectif.

Une boucle de rétroaction basée sur des mesures de position permettra à robot d'atteindre la position souhaitée : la vitesse et la direction seront adaptées en fonction de la distance à l'objectif.

Plus la boucle de rétroaction sera longue, plus l'équilibre sera long a atteindre. En effet, si la mesure de position ne se fait qu'une fois toutes les 10 secondes, soit le robot devra se déplacer très lentement, soit faire de nombreux aller-retours.

Le rapport ?

En tant qu'informaticien, il nous arrive régulièrement d'avoir à raffiner un bout de code en fonction de différents paramètres : l'expression du besoin, la rapidité d'exécution, l'occupation mémoire...

Et ce raffinage se fait par le biais d'une boucle de rétroaction qui peut prendre différentes formes :

Si la latence s'invite dans ce mécanisme, on se retrouve dans la même situation que le robot qui doit atteindre une position, mais qui n'a de retour sur sa position que rarement. Soit on avance vite et on risque les aller-retours (comprendre : réécriture du code), soit on avance lentement.

Dans tous les cas, c'est un cauchemar.

Voici quelques exemples de latence :

Un exemple concret

Avec mon collègue David nous nous sommes chargés de la résolution d'un ticket pour le projet AMO.

Afin de pouvoir présenter des graphiques d'utilisation/téléchargement des extensions à leur auteur (comme pour Firebug), toutes les requêtes de téléchargement et de demande de mise à jour sont enregistrées et stockées dans une base de données « big data » (pour les curieux : c'est stocké dans Hadoop et récupéré par le biais de Hive). On parle de plus d'un milliard de requête par jour, toutes requêtes confondues.

Ce qui nous a d'abord paru simple et rapide à implémenter, s'est transformé en deux semaines de sprint (et n'est pas encore terminé).

Nous avons subit et fait partie des différentes formes de latences listées ci-dessus :

La solution

Diminuer la latence dans la boucle de rétroaction, par tous les moyens possibles.

De la même manière qu'il arrive régulièrement de lancer un interpréteur Python (ou un ipdb ;) pour bidouiller et expérimenter avec un petit bout de code et avoir des retours immédiats, il faut tout faire pour accélérer la boucle de rétroaction.

Et à ma plus grande honte, ne pas avoir de tests unitaires a été un boulet supplémentaire : lancer un post-traitement pour s'apercevoir 15 minutes plus tard qu'on a oublié une virgule dans le code...

All posts

  1. Heartbleed, conséquences pour les utilisateurs
  2. DjangoCon Europe
  3. Objets ou fonctions
  4. Quitter Gmail : gestion des contacts
  5. Quitter Gmail : migrer ses mails
  6. Quitter Gmail : créer son compte mail
  7. Quitter Gmail : réserver son nom de domaine
  8. Quitter Gmail
  9. Au revoir Novapost, bonjour FruitLab
  10. Retour sur Pytong 2013
  11. Retour sur Sud Web 2013
  12. Django1.5 : passer au Configurable User Model
  13. Le sport
  14. Création d'un FabLab sur Valence
  15. Lancement de FaitMain.org
  16. Djangocon 2012 Tolosa Edition
  17. Taxonomie des entreprises
  18. Plan de carrière d'un développeur
  19. Automatiser son flake8 avec vim et syntastic
  20. Vim + Screen : le pair-prog des champions !
  21. Le miroir PyPI du pauvre
  22. Vim, Restructured Text et espaces insécables
  23. VIM et la correction orthographique
  24. Djangocong 2012 !
  25. Point-virgule
  26. La bidouille django du jour: appeller un templatetag depuis un autre templatetag
  27. Contribuer à Django, premiers pas (patcher la doc)
  28. Sud Web, c'est bon pour ton web
  29. Contribuer à Django, premiers pas (les outils, l'environnement)
  30. Contribuer à Django, premiers pas (revue de tickets)
  31. Djangocong 2011 : une cuvée d'exception
  32. django et le handler500: retourner une erreur 503
  33. La technique pomodoro : retour après plus d'un mois d'utilisation
  34. La technique pomodoro : retour après deux semaines d'utilisation
  35. django: redimensionner une image à la volée en préservant son ratio
  36. Django forms, HTML5 et fieldsets
  37. Double encodage utf8 : afficher correctement avec python et django
  38. La vie a la couleur qu'on veut bien lui donner
  39. lancer gunicorn avec supervisord
  40. PyCon.fr 2010 : retour sur une conférence organisée par l'AFPY
  41. djangocong : rencontre Django à Marseille
  42. MySQL, mysqldump et PHP : convertir de latin1 vers utf8
  43. Django : Envoyer des emails HTML avec images inline (intégrées)
  44. lancer gunicorn avec runit
  45. gunicorn: un server wsgi ultra simple à utiliser et configurer
  46. Installer PIL (Python Imaging Library) facilement avec pip
  47. Obfuscation de l'email alternative et accessible
  48. Linux: savoir si le processeur est 32bits ou 64bits
  49. PyCON.fr, excellent!
  50. PyCon.fr: venez m'y voir!
  51. Le contrôle de versions de sources: pourquoi?
  52. Django, sqlite et mod_wsgi, attention au piège!
  53. Checklist: différences entre MySQL et les modèles Django
  54. MySQL et les modèles Django
  55. Apprendre à faire, et faire
  56. Django FileField et ImageField, upload_to et shell python
  57. Django svn et mod_wsgi, attention au piège!
  58. 30 ans, et toutes mes dents