Retour sur son Flash Talk en vidéo :

Si vous êtes passionné par Ansible, les containers et les infrastructures Cloud, vous pouvez rejoindre Cyril dans son quotidien, postulez sur notre offre "Ingénieur Système et Réseaux (Orienté Linux) H/F"

En plus du sponsoring, Wifirst sera présent par l'intermédiaire de nos conférenciers qui ont été sélectionnés par l'organisation.

Samedi 2 Novembre à 14h30, Romain Bellan animera une session de "live coding" intitulée "JE CONSTRUIS MON PREMIER MOTEUR (ASYNCHRONE) DE PYTHON 2 À PYTHON 3.7"

Et à 16h30 le même jour, Florent Fourcot ainsi que Charles Daymand et Victorien Molle animeront la conférence "CONFIGUREZ / TRACEZ / DÉBUGUEZ VOTRE NOYAU LINUX AVEC PYTHON"

Ensuite, le 18 et 19 Novembre aura lieu la conférence Sysadmin Days #9 à Paris

A cette occasion, mardi 19 Novembre à 11h40, Cyril Grosjean fera un flask talk sur "MOLECULE, OU COMMENT TESTER SES ROLES ANSIBLE"

N'hésitez pas à venir voir nos intervenants pour en savoir plus sur notre savoir-faire. RDV à la Pycon ou aux Sysadmin Days

Lors de cette conférence, nous allons parler de la sécurité des points d'accès WiFi Ruckus et Aerohive. En effet, ceux-ci étaient vulnérables à des élévations de privilèges permettant de prendre la main en mode super-utilisateur et nous octroyant ainsi tous les droits sur le système (plus de détails ici).

Vous pouvez retrouver le planning des conférences à cette adresse : https://www.sstic.org/2019/programme/. A vendredi !

Du côté du probablement moins connu, Dnsmasq contient également aussi beaucoup d'options, qui permettent de l'adapter à beaucoup de situations. Un exemple est sa capacité à ajouter les adresses IP des noms qu'il résout en DNS dans des ipset. Loin d'être anodine, cette fonctionnalité permet par exemple de mettre en place des autorisations/interdictions en fonction de noms de domaines (ce qui a forcément des effets de bords, notamment du fait des CDN de plus en plus nombreux, mais c'est un autre sujet).

Pour ces raisons, nous utilisons Dnsmasq sur beaucoup de nos équipements. Reste une question : ce petit démon, léger, embarqué habituellement pour sa simplicité, peut-il passer à l'échelle ? Son site officiel le définit comme « Dnsmasq provides network infrastructure for small networks ». Quand on lit le mot small, un premier réflexe pourrait être de basculer vers des solutions comme isc-dhcp-server quand le réseau grossit. Mais si l'on souhaite avoir un parc homogène, peut-on imaginer garder Dnsmasq pour des réseaux plus volumineux ? (spoiler : la réponse est oui, voici un retour d'expérience).

Le premier palier, qui n'existe pas vraiment

La première configuration est relativement évidente. Par défaut, la valeur pour dhcp-lease-max est configurée à 1000. C'est rapidement insuffisant, et l'augmenter va de soit. À noter que la page de manuel parle d'un risque sur la consommation mémoire, mais il est à relativiser. Un dnsmasq avec plus de 10 000 baux en mémoire consomme moins de 5Mo de RAM. On peut l'augmenter sans crainte sur la plupart des équipements.

Second paramètre à prendre en compte, l'option dhcp-ignore-names. Par défaut Dnsmasq va insérer les noms annoncés par les clients en DHCP dans ses entrées DNS. C'est sympa/pratique sur un petit réseau local personnel. C'est par contre à bannir rapidement sur un réseau professionnel. Si malgré les risques de sécurité quelqu'un souhaite cependant la conserver sur un grand réseau, on voit rapidement apparaître des problèmes de performances dès quelques milliers de baux en mémoire. Notamment car Dnsmasq va vérifier à chaque requête DHCP que ce nom n'existe pas déjà sans sa liste, ce qui est très lent.

Avec ces deux paramètres, vous pouvez déjà avoir un réseau de grande taille (plusieurs milliers de baux) sans détecter la moindre consommation CPU de Dnsmasq.

Le bug qui coûte une seconde par bail

Le palier suivant a été détecté chez nous sur une configuration qui dépassait les 15 000 baux alloués dans la journée. Sur ce site spécifique, ces baux étaient libérés durant la nuit (durée de quelques heures, et aucune activité réseau après minuit. Atypique pour nous, qui avons plutôt des utilisateurs nocturnes et de longue durée). Nous avons remarqué une consommation CPU anormale, Dnsmasq consommant bien plus de CPU la nuit (alors qu'il ne faisait que supprimer ses baux) qu'en journée.

Après analyse, il s'agit d'un bug de Dnsmasq qui déclenche un nettoyage de ses sessions à l'heure exacte d'expiration du prochain bail, mais ne le nettoie effectivement qu'une seconde après cette expiration. Résultat, durant une seconde Dnsmasq boucle sur ce nettoyage qu'il relance en permanence sans accomplir la moindre action. On perd ainsi une seconde de temps processeur pour chaque bail supprimé.

Cet effet est complètement invisible sur un petit réseau. Dans notre cas, en libérant 15 000 baux en quelques heures, notre processeur était occupé pendant plus de quatre heures pour rien. Pour la petite histoire, on voyait même apparaître la fonction difftime avec perf tant Dnsmasq passait son temps à vérifier si un bail de sa liste était expiré et la date de prochaine expiration.

Nous avons donc proposé un patch, rapidement accepté (et déployé immédiatement sur nos équipements), qui permet de revenir sur une situation beaucoup plus calme (on ne voit plus Dnsmasq consommer du CPU durant la nuit, ce qui est tout de même plus logique).

Encore plus loin

Arrivé là, on a déjà un Dnsmasq qui consomme de façon très raisonnable des ressources pour un réseau voyant passer plus de 20 000 équipements différents dans la journée. Cela devrait suffire pour la plupart des réseaux.

Pour aller plus loin, le prochain problème est l'écriture du fichier dnsmasq.leases par Dnsmasq à chaque changement d'état. Sur ce type de réseau, on se retrouve à ré-écrire un fichier de milliers de lignes à chaque seconde ou presque (voir plus souvent). De plus, comme effet de bord, Dnsmasq ré-écrit le fichier plutôt que d'effectuer une opération atomique avec un fichier temporaire, provoquant des effets de bords dans d'éventuels programmes externes tentant de le lire (le fichier est souvent invalide, partiellement écrit). Cette ré-écriture est suffisamment intense pour qu'on voit apparaître la fonction vsnprintf avec perf, ce qui n'est pas très bon signe.

Heureusement Dnsmasq permet une nouvelle fois par ses nombreuses options d'éviter ça. Avec l'option dhcp-script, un script est appelé à chaque changement d'état DHCP (ajout, suppression, modification). On peut donc maintenir une base des baux nous même, et permet déjà à des outils de supervision d'éviter les problèmes de ré-écriture en permanence du fichier dnsmasq.leases. Cependant, on ne diminue pas encore la consommation de ressource.

La solution arrive avec leasefile-ro, qui permet cette fois de s'affranchir entièrement de ce fichier. L'astuce à ajouter est de permettre à Dnsmasq de retrouver les baux DHCP actifs lors d'un redémarrage. C'est assez simple, dans ce cas Dnsmasq appelle le script habituel avec en paramètre init. Il suffit de lui afficher sur stdin les baux actuels dans le même format que son fichier habituel et tout roule. C'est assez simple à faire si l'étape précédente de maintien d'une base externe fonctionne déjà.

À noter que Dnsmasq permet d'utiliser des scripts en lua plutôt que des scripts externes (et qu'on pourrait donc s'attendre à des gains en ressource), mais qu'à ce jour les scripts lua ne permettent pas de charger les baux au démarrage avec init. Ils ne sont donc pas utilisables pour ce cas d'usage.

Prochain palier ?

En conclusion, Wifirst utilise donc Dnsmasq sur des réseaux qui ne voient que quelques équipements dans la journée à des réseaux de bien plus grande envergure. Et ça se passe aujourd'hui très bien, la consommation de ressource de Dnsmasq étant négligeable avec ces configurations par rapport aux autres fonctionnalités.

Nous avions commencé à stocker notre propre base de baux DHCP pour des raisons de supervision (une autre solution serait d'améliorer Dnsmasq pour faire des changements atomique sur le fichier). L'utiliser pour améliorer les performances est un petit bonus, pas indispensable d'après notre expérience sur des réseaux ayant jusqu'à 20 000 baux alloués et libérés dans la journée.

Et nous attendons donc avec impatience de voir ce que pourrait être le prochain point de blocage. Un suspect probable est à regarder du côté des appels à dhcp-script, mais nous n'imaginons pas pour le moment voir de réseaux d'une taille suffisante pour que ce soit détectable.

La version 7 d'ipset est sortie récemment (mais pas encore dans la branche principale du noyau, elle devrait arriver en 4.20 ou 5.0). Et Wifirst y est un peu pour quelques chose.

Nous utilisons massivement les ipset sur nos équipements, notamment car ils permettent de configurer un pare-feu basé sur iptables entièrement vers netlink (et aussi car il permet de rendre dynamique un pare-feu iptables classique, sans ajouter/modifier de règles). C'est donc assez naturellement que nous avons également commencé à les utiliser pour configurer une partie de notre QoS (commande tc). Nous avons ainsi ajouté le support des ipset par tc-ematch dans pyroute2.

Il restait cependant un problème pour nous qui n'utilisons que du netlink. Pour convertir le nom d'un ipset en un index utilisable par le noyau pour ajouter la règle, le module tc-ematch fait ceci :

static int
get_set_byname(const char *setname, struct xt_set_info *info)
{
    struct ip_set_req_get_set req;
    int res;

    req.op = IP_SET_OP_GET_BYNAME;
    strlcpy(req.set.name, setname, IPSET_MAXNAMELEN);
    res = do_getsockopt(&req);
    if (res != 0)
        return -1;
    if (req.set.index == IPSET_INVALID_ID)
        return -1;
    info->index = req.set.index;
    return 0;
}   

Ils utilisent donc getsockopt plutôt que netlink. C'est un peu dommage pour un module qui autrement fonctionne entièrement en netlink. Nous avons donc proposé un patch permettant d'exporter ces index, en ajoutant un flag pour contrôler son affichage afin de ne pas casser les outils existants en espace utilisateur. Pour les curieux, cette interface via getsockopt a quatre options définies dans ip_set.h.

Ce patch a été refusé, le mainteneur ne souhaitant pas introduire ce type de changement sans augmenter le numéro de version du protocol. IPSet version sept était donc né ! Quelques mois après notre demande initiale, le mainteneur a proposé sa version, ajoutant deux commandes ip_set_byname et ip_set_byindex.

Peu après sa mise à disposition, nous avons pu tester et travailler sur la gestion par pyroute2 de ces commandes avec pour but de supprimer nos patchs maintenus en interne.

Sous Linux, chaque namespace réseau a sa propre table Conntrack, complètement isolées entre elles. Elles se rejoignent en revanche sur la taille maximale, partout la même, et configurable uniquement en sysctl (voir le fichier /proc/sys/net/netfilter/nf_conntrack_max). Ainsi, une modification de taille effectué depuis n'importe quel namespace aura des conséquences partout.

Apparemment pour des raisons de compatibilité avec de noyaux, notre supervision lisait un alias de ce fichier, sous le chemin /proc/sys/net/nf_conntrack_max (les chemins précédents en ip_conntrack ayant été supprimés en 2016). Contrairement au « véritable » fichier dans le dossier netfilter, celui-ci n'est exporté que sur le namespace principal :

$ cat /proc/sys/net/netfilter/nf_conntrack_max
262144
$ ip netns exec namespace1 cat /proc/sys/net/nf_conntrack_max
cat: /proc/sys/net/nf_conntrack_max: No such file or directory
$ ip netns exec namespace1 cat /proc/sys/net/netfilter/nf_conntrack_max
262144

Quitte à regarder cette partie de notre supervision, nous avons décidé d'harmoniser la récupération du nombre d'entrées (que nous récupérions en netlink) avec la récupération du nombre maximum. C'est l'idée derrière ce patch.

Signe que nous n'étions probablement pas les seuls à avoir ce besoin, un contributeur externe a ajouté la gestion par pyroute2 avant que nous ayons intégré cette partie de notre côté.

En problème relié à tout ça, on peut également noter qu'openvswitch permet depuis peu de limiter le nombre d'entrées conntrack par zone.

Même si Python 3 n'est pas fondamentalement différent de Python 2 et qu'il existe de nombreux outils pour aider à porter son code, le portage d'un projet entier ne se fait jamais entièrement sans difficulté et est souvent l'occasion d'en apprendre plus sur notre langage préféré.
Comme on va le voir, c'est aussi une bonne manière de découvrir des problèmes insoupçonnés dans son code !

Un peu de contexte(s): gestion du réseau chez Wifirst

J'ai récemment été amené à travailler sur la compatibilité Python 3 de notre code de gestion du réseau (adressage, routage, etc). Nous utilisons le projet pyroute2, auquel nous contribuons régulièrement, pour s'interfacer avec le noyau via l'API Netlink.

La base de pyroute2 est une classe d'assez bas niveau (IPRoute), dont l'instanciation provoque l'ouverture d'une socket Netlink. Pour faire simple, nous appellons l'ensemble "contexte IPRoute".

Nous avons implémenté notre propre module d'abstraction utilisant massivement ces contextes. Il nous permet de gérer par exemple les adresses et les routes sans avoir à rentrer dans les détails des structures Netlink exposées par les méthodes d'IPRoute.
Afin de ne pas avoir à gérer le cycle de vie de ces contextes à chaque appel à nos fonctions d'abstraction, un motif récurrent que l'on y retrouve est le suivant:

@needs_iproute_context
def do_something_network_related(arg1, arg2, ipr=None):
    # do stuff
    other_network_related_things("yeah", arg2, ipr=ipr)

Le décorateur needs_iproute_context inspecte les arguments de la fonction décorée et, s'il y trouve un argument nommé "ipr" dont la valeur est None, le remplace par un contexte IPRoute qu'il ferme après l'appel. Cela nous permet de pouvoir appeler toutes nos fonctions de routage sans avoir à instancier de contexte IPRoute par nous-même, et tout en évitant d'en instancier un pour chaque appel de fonction.

En voici une implémentation simplifiée:

from pyroute2 import IPRoute
def needs_iproute_context(fun):

    def wrapped(*args, **kwargs):
        if kwargs.get("ipr"):
            return fun(*args, **kwargs)
        else:
            with IPRoute() as ipr:
                kwargs["ipr"] = ipr
                return fun(*args, **kwargs)
    return wrapped

Un souci de portabilité pas commun

Dans la majeure partie des cas, pas de problème; needs_iproute_context fonctionne aussi bien en Python 2 qu'en Python 3. Mais dans un cas particulier, ce décorateur était utilisée d'une manière un peu plus exotique (code également simplifié):

@needs_iproute_context
@contextmanager
def temporary_route(dst, gateway, ipr=None):
    ipr.route("add", dst=dst, gateway=gateway)
    yield
    ipr.route("del", dst=dst, gateway=gateway)

Ce gestionnaire de contexte nous permet de mettre en place une route de manière temporaire, qui est supprimée dès que l'on sort du bloc with. Par exemple, ce bloc rajoute une route temporaire, l'affiche et la supprime:

with temporary_route(dst="66.96.149.1/32", gateway="10.4.1.2"):
    with IPRoute() as ipr:
        for i in ipr.get_routes(dst="66.96.149.1/32"):
            print(i.get_attr("RTA_GATEWAY"))

Et c'est là que les soucis commencent. temporary_route fonctionne parfaitement en Python 2, mais échoue invariablement en Python 3:

$ sudo python3 temporary_route.py 
Traceback (most recent call last):
  File "temporary_route.py", line 39, in <module>
    with temporary_route(dst="66.96.149.1/32", gateway="10.4.1.2"):
  File "/usr/lib/python3.6/contextlib.py", line 81, in __enter__
    return next(self.gen)
  File "temporary_route.py", line 19, in temporary_route
    ipr.route("add", dst=dst, gateway=gateway)
  File "/usr/lib/python3/dist-packages/pyroute2/iproute.py", line 1750, in route
    callback=callback)
  File "/usr/lib/python3/dist-packages/pyroute2/netlink/nlsocket.py", line 804, in nlm_request
    return do_try()
  File "/usr/lib/python3/dist-packages/pyroute2/netlink/nlsocket.py", line 780, in do_try
    self.put(msg, msg_type, msg_flags, msg_seq=msg_seq)
  File "/usr/lib/python3/dist-packages/pyroute2/netlink/nlsocket.py", line 561, in put
    self.sendto_gate(msg, addr)
  File "/usr/lib/python3/dist-packages/pyroute2/netlink/rtnl/iprsocket.py", line 74, in _gate
    return self._sendto(msg.data, addr)
OSError: [Errno 9] Bad file descriptor

Visiblement, l'ajout de route n'a pas fonctionné, car l'envoi du message sur la socket netlink a échoué. Mais pourquoi cette différence entre les deux versions de Python ?

Le message d'erreur indique qu'il y a un problème sur la socket Netlink. Pour voir ce qu'il en est, on peut poser un point d'arrêt avant l'ajout de la route pour inspecter le contexte IPRoute:

> /home/etienne/work/article-devblog/temporary_route.py(22)temporary_route()
-> ipr.route("add", dst=dst, gateway=gateway)
(Pdb) p ipr
<pyroute2.iproute.IPRoute object at 0x7fd503f77b70>
(Pdb) p ipr.closed
True
(Pdb)

La sortie est la même en Python 2 et 3: le contexte IPRoute est déjà fermé.

Pourquoi est-il fermé, et comment est-ce possible que ça fonctionne quand même en Python 2 ? C'est le moment de ressortir le fidèle strace, qui pourra nous en dire plus long sur ce qu'il se passe réellement niveau socket. En relançant avec le point d'arrêt + strace:

$ sudo strace -e socket,close python2 temporary_route.py
[...]
socket(AF_NETLINK, SOCK_DGRAM, NETLINK_ROUTE) = 5
close(4)                                = 0
close(3)                                = 0
close(3)                                = 0
> /home/etienne/work/article-devblog/temporary_route.py(24)temporary_route()
-> ipr.route("add", dst=dst, gateway=gateway)
close(3)                                = 0
(Pdb) p ipr.closed
True

$ sudo strace -e socket,close python3 temporary_route.py
[...]
socket(AF_NETLINK, SOCK_DGRAM|SOCK_CLOEXEC, NETLINK_ROUTE) = 5
close(4)                                = 0
close(3)                                = 0
close(5)                                = 0
close(3)                                = 0
> /home/etienne/work/article-devblog/temporary_route.py(24)temporary_route()
-> ipr.route("add", dst=dst, gateway=gateway)
(Pdb) p ipr.closed
True

Dans les deux cas, une socket Netlink est ouverte (descripteur de fichier numéro 5), mais elle est fermée avant l'ajout de la route en Python 3, alors qu'elle reste ouverte en Python 2 ! Par contre, l'objet IPRoute associé est considéré comme fermé.

On a donc deux soucis:

• le contexte IPRoute fermé avec sa socket toujours ouverte,
• le fait qu'il soit fermé dans needs_iproute_context

La socket de Schrödinger

Pour confirmer ce problème de socket considérée comme fermée par l'objet IPRoute alors qu'elle est toujours ouverte par le système, on peut faire un test simple :

from pyroute2 import IPRoute
ipr = IPRoute()
ipr.get_links()
ipr.close()
ipr.get_links()

Ça "fonctionne" en Python 2, mais en Python 3 le deuxième appel à get_links échoue.
C'est ennuyant pour nous, car le comportement en Python 3 est correct, ce qui signifie que temporary_route n'aurai jamais dû fonctionner.

Pourquoi cette différence de comportement ? Étant donné que le code de pyroute2 est le même pour Python 2 et 3, j'ai regardé s'il y avait une différence dans la fermeture des sockets dans le module socket de Python. Et c'est effectivement le cas:

Python 2.7:

def close(self, _closedsocket=_closedsocket,
          _delegate_methods=_delegate_methods, setattr=setattr):
    # This function should not reference any globals. See issue #808164.
    self._sock = _closedsocket()
    dummy = self._sock._dummy
    for method in _delegate_methods:
        setattr(self, method, dummy)

Python 3.6:

    def close(self):
        # This function should not reference any globals. See issue #808164.
        self._closed = True
        if self._io_refs <= 0:
            self._real_close()

En Python 2, les méthodes associées à la socket (_delegate_methods), comme sendto et recv sont remplacées lors de la fermeture par des méthodes factices qui se contentent de lever une erreur, pas en Python 3.

Pendant ce temps là, du côté de pyroute2:
(extrait de NetlinkSocket.post_init)

self._sendto = getattr(self._sock, 'sendto')
self._recv = getattr(self._sock, 'recv')
self._recv_into = getattr(self._sock, 'recv_into')

La classe NetlinkSocket copie lors de son initialisation une référence vers les méthodes de la socket. En Python 2, cela créé un état incohérent lors de la fermeture: la socket a remplacé ses méthodes par des factices, mais NetlinkSocket pointe toujours sur les "vraies" méthodes. Des donnés peuvent donc toujours être envoyées sur la socket si elle n'a pas encore été fermée au niveau système, ce qui semble être le cas.

Considérant que ce comportement était un bug, j'ai ouvert une pull request sur pyroute2, une correction rapide de NetlinkSocket qui fait en sorte de ne plus garder une référence sur des méthodes qui peuvent avoir changé.

Décorer un gestionnaire de contexte ?

Avec un comportement correct de fermeture des sockets par pyroute2, on se retrouve avec un autre problème: temporary_route ne fonctionne pas du tout car la socket est fermée avant même d'entrer dans ce gestionnaire de contexte.

Les plus versés dans les arcanes de Python auront peut être déjà compris pourquoi, mais pour ceux (moi inclus) pour qui ça ne tombe pas sous le sens, réécrire le gestionnaire de contexte dans sa forme non condensée (c'est à dire sans utiliser le décorateur contextmanager) rend les choses bien plus claires:

class TemporaryRoute(object):

    @needs_iproute_context
    def __init__(self, dst, gateway, ipr=None):
        self.ipr = ipr
        self.dst = dst
        self.gateway = gateway

    def __enter__(self):
        self.ipr.route("add", dst=self.dst, gateway=self.gateway)

    def __exit__(self, *_):
        self.ipr.route("del", dst=self.dst, gateway=self.gateway)

needs_iproute_context ne peut pas décorer un gestionnaire de contexte, car c'est une classe. Que l'on décore le constructeur ou la classe elle-même, cela revient au même; le contexte est fermé implicitement à la fin du bloc with IPRoute() as ipr: de needs_iproute_context et n'est donc valable que dans __init__.

La meilleure solution a donc été de réimplémenter temporary_route pour gérer son propre contexte IPRoute, ce qui fonctionne à la fois en Python 2 et 3.

Au final

Porter un seul gestionnaire de contexte aura permis de trouver un souci dans pyroute2, un autre dans notre code, et d'en apprendre davantage sur le Python; le portage vers Python 3 est donc un bon investissement !

Par un heureux hasard, je me suis retrouvé à être interviewé par l'auteur du livre Mastering PostgreSQL in Application Development. Comme l'exercice de l'interview ne se prête pas complètement aux détails techniques, j'en profite pour compléter ici un peu ce que nous avons changés sur nos django.

Premier exemple assez trivial, nous avions du code qui vérifiait si un objet n'avait pas été vu depuis un certain temps. L'approche précédente était de faire cette vérification en python :

    def is_seen(self, now=None):
        if self.last_seen is None:
            return False
        
        if now is None:
            now = timezone.now()
        return now - self.last_seen < LOST_DELTA

La micro-optimisation sur la variable now n'est pas très importante, sauf quand cette méthode est appelée sur des milliers d'objets différents.

Ce n'est pas très spectaculaire, mais nous avons ajouté une simple méthode sur le manager de l'objet :

    def add_connected(self):
        return self.annotate(connected=Case(When(last_seen__gt=(timezone.now() - LOST_DELTA),
                                                 then=Value(True)),
                                            default=Value(False),
                                            output_field=BooleanField()))

On a ainsi directement un attribut booléen sur tous les objets quand nous en avons besoin.

Second exemple, nous avons dans notre modèle de base de données des lignes ADSL. Ces lignes ADSL sont liées à des sites (un site pouvant avoir N lignes). Nous souhaitons savoir très rapidement si un site a une ligne ADSL ou pas. Le code existant utilisait la solution standard en Django en utilisant un JOIN avec un DISTINCT :

Site.objects.filter(line__isnull=False).order_by("pk").distinct("pk")

Cela générait ce genre de requête SQL :

SELECT DISTINCT ON ("appli_site"."id") "appli_site"."id", "appli_site"."name"
FROM "appli_site" INNER JOIN "appli_line" ON ("appli_site"."id" = "appli_line"."site_id")
WHERE "appli_line"."id" IS NOT NULL ORDER BY "appli_site"."id"

Ce n'est malheureusement pas très efficace. Il y a d'ailleurs un bug ouvert à ce sujet sur le projet Django.

Nous l'avons remplacé par un EXIST, environ quatre fois plus efficace sur notre application :

SELECT "appli_site"."id", "appli_site"."name" FROM "appli_site"
WHERE (EXISTS (SELECT 1 FROM "appli_line" WHERE "appli_line"."site_id" = "appli_site"."id"

En attendant que la fonctionnalité existe chez Django, nous avons également rajouté une méthode sur le manager de l'objet :

def has_line(self): 
    return self.extra(where=['EXISTS (SELECT 1 FROM "appli_line" WHERE "appli_line"."site_id" = "  appli_site"."id")'])

Dernier exemple, nous voulions compter les points d'accès WiFi joignables et non joignables, par site. Tout comme les lignes, les objets points d'accès sont liés aux sites par un ForeignKey.

Le code précédent itérait sur l'ensemble des points d'accès, et s'occupait du comptage en python dans un dictionnaire (le code est simplifié, notamment le nom des variables est réduit pour simplifier la lecture) :

for site_id, is_reachable in AP.objects.values_list('site', 'is_reachable'):
    key = 'ok' if is_reachable else 'down'
    counters[site_id][key] += 1

Quand le nombre d'objets AP est très important, cela génère beaucoup de lignes de résultats à transférer (et encore, on ne génère pas d'objets python en utilisant values_list). Une meilleure solution tout en SQL :

SELECT "appli_site"."id",
       (COUNT("appli_ap"."mac") FILTER (WHERE is_reachable = true)) AS "ap_oks",
       (COUNT("appli_ap"."mac") FILTER (WHERE is_reachable = false)) AS "ap_downs"
FROM "appli_site" LEFT OUTER JOIN "appli_ap" ON ("appli_site"."id" = "appli_ap"."site_id")
GROUP BY "appli_site"."id"

Quand le nombre de site est faible par rapport au nombre de points d'accès (ce qui est très vrai dans notre cas), cette requête va beaucoup plus vite que l'évaluation en python. À noter que cette requête est possible entièrement en Django à partir de la version 2.0, grâce au niveau paramètre filter ajouté aux aggrégations.

Ce ne sont pas les seules optimisations, mais avec d'autres petits changements (un jour de développement), on a réussi à arriver au résultat cité dans l'interview, à savoir une diminution par cinq des données transférées entre la base de données et l'application Django.

Si nous avons pris l'habitude de nous rendre à la Pycon-fr tous les ans, nous avons pour la première fois cette année également participés en tant que présentateurs à cette édition à Toulouse.

Notre première présentation (chronologiquement) parlait d'une bibliothèque Python (pyroute2) que nous utilisons massivement et sur laquelle nous contribuons en maintenant les modules concernant les ipsets, ainsi que par des patchs divers et variés. Même si le son n'est pas terrible (je n'avais pas de micro), la vidéo est disponible, ainsi que les slides.

La seconde était une présentation plus générale de nos activités et un retour d'expérience sur les outils que nous utilisons (ansible, SNMP en python, etc). De la même façon, la vidéo et les slides sont disponibles.