Quelle techno pour une API à haute performance ?

Question

Je vais devoir mener à bien un projet d'API JSON ayant de fort critères de performance. En effet, ce dernier doit pouvoir tenir la charge face a un nombre conséquent d'utilisateur requérant des calculs assez compliqué liés a de la géolocalisation, du calcul d'itinéraires et autres joyeusetés géographiques et temporelles.

Je n'ai jamais été confronté a des problématiques de cette ampleur et j'avoue avoir du mal a m'y retrouver dans les nombreuses possibilités qui s’offrent à moi, et souhaiterai avoir vos conseils, non pas sur la meilleur techno (qui est un concept qui je pense n'existe pas) mais simplement sur la plus adapté à mon besoin.

Mes recherches préliminaires m'ont menés vers :

• Django + Django REST Framework : Déjà utilisé par le passé sur des projets de moindre ampleur, je le sais assez facile de prise en main, mais j'ai un peu peur de son coté "automagique" et des performances si l'API est beaucoup sollicité...

• Tornado : De ce que j'ai comprit, c'est beaucoup plus "bas niveau" que Django, (puisque on descend jusqu'au serveur web lui-même) et donc donne un meilleur contrôle sur ce qui se passe en coulisse, et par la même, de meilleur possibilités d'optimisation. Mais on y perd en facilité d'utilisation. Le gain sera t-il vraiment significatif ?

• Peut-être avez vous une suggestion de quelque chose de plus adapté ? J'ai vu passer beaucoup de noms mais difficile de s'y retrouver : Pyramid, Bottle, Flask, cherrypy etc...

A toutes fin utiles, je cherche des solutions compatibles Python3.5

Comments

"fort critères de performance" est très vague. Combien d'utilisateurs ? Sur combien de temps ? Quels calculs ? Tous les combiens ? Les perfs seront limitées par l'IO ou par le CPU ? Y a-t-il des contraintes de fraicheurs d'information ? De budget pour le dev ? Le paiement de l'hébergement ?Y a-t-il une deadline ? Quelles sont le niveau des devs en internet ? Etc.

---

Effectivement, ton message laisse penser que le problème de performance risque de se poser au niveau du serveur, or c'est loin d'être acquis. Il faut absolument que tu identifie correctement le(s) goulot(s) d'étranglement possible(s), avant de choisir ta stack.

Est-ce que ce sera surtout les calculs qui vont bouffer le temps CPU ? Ou bien le nombre d'utilisateurs qui risque de mettre ton serveur à genoux ? Ton backend fait appel à des serveurs potentiellement lents ? La quantité de données à transmettre est importantes ? Etc.

---

Combien d'utilisateurs : Si tout se passe bien, plusieurs dizaine de milliers journalier

Sur combien de temps : On parle de quoi ? De la durée d'une session ? J'ai pas assez de visibilité la-dessus

Quels calculs : Un calcul d'itinéraire le plus court entre plusieurs points (type voyageur de commerce tout ça... d'où les problèmes de perfs)

Perf limités par : Le CPU. On flirte dangereusement avec le problème NP-Complet et il risque d'y avoir beaucoup de possibilités d'itinéraires a tester. En I/O je pense que devrais pas être top limité (sortir une liste de points depuis une BDD avec les bons index devraient pas être trop couteux)

Fraicheurs d'infos : A moins que les points ne changent (et en théorie, ils ne bougeront pas des masses puisqu'on parle ici de bâtiments), pas trop de problème de ce coté là.

Budget : On prendra ce qu'il faut.

Hébergement : Sur du Amazon EC2 pour être facilement dimmensionable au fur et a me sure du grossissement de la plate-forme

Deadline : Je dois présenter un proto, même fait un peu a l'arrache d'ici 4-5 mois

Niveau des devs : Je suis seul. J'ai fait pas de mal de petit projets perso en python (Basé sur Django). Mais le mot-clé, c'est petit (en général, j'étais le seul visiteur ou presque). Or la on parle de chiffres de visites qui dépassent de beaucoup ce à quoi je suis habitué

PS : Merci pour l’intérêt que tu porte a ma question
PS2 : C'est beaucoup grâce à toi et Max si je code en python. Donc j'en profite pour dire merci, parce que j'ose pas trop commenter sur le blog ^^

Answer 1

Ton bottleneck ne sera pas du tout lié à l'API. Quelle que soit la techno que tu utilises, ça ne sera pas la limite (aucun framework ne tombe à 10000V/J) donc tes perfs seront limitées par l'algo de ta recherche de routes;

Donc tu peux choisir la technos sur d'autres critères comme la flexibilité, la facilité d'utilisation, etc;

Dans ton cas, tu peux éviter de te lancer sur tornado ou autre, puisque pas de problème de perfs en IO côté requêtes, donc autant rester sur des trucs simples. Mais tu as un peu de temps, donc tu peux te permettre d'investir quelques jour pour apprendre à utiliser un outil assez complet.

Pour moi, Django Rest Framework serait donc le meilleur choix. Il est moins rapide que tornado, et plus long à apprendre que d'autres outils, mais globalement c'est l'outil le plus souple, de très bonne qualité et qui produit un résultat propre tout en s'inscrivant dans un écosystème riche.

Comments

Pour ma culture personnelle, et puisque c'est lié a la question et que c'est le genre d'informations que quelqu'un pourrait vouloir trouver en tombant sur cette page, tu dis qu'a 10000 V/J aucun framework ne tombe, alors a combien estimerais-tu le nombre d'utilisateur quotidien requis pour que ça devienne un vrai problème. A partir de combien conseillerait tu de passer a Tornado ?

---

Tornado c'est plus si tu as des connections longues ouvertes genre si tu veux beaucoup d'ajax ou de websocket : chat, notifications temps réel, etc. Là Si tu commences à avoir 50 users connectés en même temps qui monopoliserait un thread chacun avec Django, c'est utile de faire du Tornado. Mais 10000V/J 30 users en simultané en moyenne, allez 200 aux pics. Sur des sites qui n'ont pas de connections longues ouvertes, je fais monter Django à 1000 users/simulanément sans problème.

---

@Sam +1 Je te sais deja tres pris, et je sais que cela peut etre tres subjectif, mais je suis preneur sur n'importe quel tuto ou retour d'experience concernant le dimensionnement (type hardware, type software, type stack, nbre de requetes, ...)

---

Je suis incapable de faire un tel tuto. Je fais vraiment les choses au doigt mouillé.