Django-Bolt utilise Rust pour multiplier le débit d’un endpoint JSON

Présentation

Le projet Django‑Bolt propose d’interposer un serveur HTTP écrit en Rust, basé sur Actix Web, devant une application Django existante. Le but affiché est d’augmenter le nombre de requêtes traitées par seconde tout en conservant le code Python, les modèles ORM et la logique métier. Dans les benchmarks publiés, le serveur Rust atteint 311 000 rps pour un endpoint qui renvoie simplement un objet JSON statique.

Architecture technique

Actix Web gère la couche réseau et le décodage HTTP. Lorsqu’une requête nécessite l’accès aux fonctionnalités Django (ORM, authentification, middleware), le serveur Rust invoque du code Python via PyO3, qui assure la liaison entre les deux runtimes. Cette approche minimise les changements dans la base de code Python : les modèles, les permissions et les intégrations restent inchangés, seul le serveur d’entrée est remplacé.

@api.get("/json-1k")
async def json_1k():
    return JSON_1K

Le fragment ci‑dessus montre un endpoint de test utilisé dans les mesures synthétiques : il ne fait aucune requête base de données ni aucune logique métier. Un second exemple introduit l’ORM :

@api.get("/users", response_model=list[UserSchema])
async def users():
    return [user async for user in User.objects.all()[:10]]

Analyse des performances

Le gain de throughput observé provient principalement de la capacité de Rust à gérer les connexions TCP et le parsing HTTP avec très peu de surcharge CPU. Sur un endpoint sans logique supplémentaire, le temps passé dans le serveur Rust représente la quasi‑totalité du temps de latence, d’où le chiffre de 311 k rps. Cependant, dès que la requête implique une interaction avec la base de données ou l’authentification, le chemin d’exécution bascule vers Python, où le GIL et les coûts d’ORM réintroduisent les goulots d’étranglement classiques de Django.

En pratique, les métriques de latence (p50, p95, p99) et l’utilisation CPU du processus Python restent les facteurs limitants. Un test qui ajoute une requête SELECT sur 10 enregistrements montre une réduction du débit de plusieurs ordres de grandeur, même si le serveur Rust continue de délivrer les paquets réseau rapidement. Ainsi, le ratio d’amélioration dépend du pourcentage de temps passé dans le code Python : plus la logique métier est lourde, plus le bénéfice diminue.

Limites et recommandations

Les benchmarks synthétiques ne reflètent pas la charge réelle d’une API Django typique. Pour évaluer correctement Django‑Bolt, il faut mesurer des endpoints productionnels, conserver les appels DB, l’authentification et la sérialisation, et suivre simultanément le rps, la latence et l’activité CPU de la base de données. Si le gain de débit reste significatif après ces ajouts, l’intégration Rust peut être justifiée comme optimisation ciblée. Sinon, les gains restent théoriques et le coût de maintenance d’une couche Rust supplémentaire peut dépasser les bénéfices.

En résumé, Django‑Bolt démontre que Rust peut accélérer la partie réseau d’une API Django, mais la performance globale dépend fortement du poids de la logique applicative. Les équipes doivent donc concevoir des tests réalistes avant de déployer cette architecture en production.