Alors les logs, j'avoue, j'ai pas trop d'idée de comment les rajouter avec bjoern, et je ne sais pas quel délais en plus ça prendrait...
J'ai codé un truc à l'arrache non optimisé, et je tombe à 9k req/sec.
Donc j'ai testé le bouzin en conditions un peu plus réelles sur un Odroid XU4, ARM, soft float (ça fait des années que je dois le réinstaller en HF), 8 cœurs, limités à 500Mhz pour cause de surchauffe (le ventilo est pété, la pâte thermique mérite d'être remplacée), python 3.7, à travers le réseau (gigabit, en câble pas en wifi), test ab depuis ma machine perso.
700 req/s.
Bon, OK, je libère le CPU 2 minutes en espérant qu'il ne crashe pas : 4x1.4Ghz et 4x2Ghz.
1800 req/s.
À noter que si je passe à 20 connexions en parallèle, on monte à 3300 req/s, parce qu'on a la latence réseau à prendre en compte, et 8 coeurs en face, donc pour les surcharger, 10 connexions parallèles ne suffisent pas.
On monte même à 3500 avec 100 requêtes parallèles, alors que en local ça ne changeait rien de monter au delà de 10.
Bon, voilà, à moins de trouver autre chose que je ne connais pas, je ne ferais pas mieux en Python sur ma machine.
J'avais testé plusieurs serveurs python derrière un apache ou un haproxy en mode load-balancer, d'autres backends que bjoern (waitress est pas mal par exemple), sur un autre projet qui consistait à servir une image aléatoire dans une liste à chaque requête. L'idée était de les précharger en python au début, avec le type, la taille et le contenu, et de servir les headers direct, et le contenu, sans jamais relire sur le disque.
On a exactement les mêmes perfs que la simple redirection, 13-14k req/s, avec des icônes, donc de petites images.
J'ai jamais réussi à faire mieux en python qu'une app bottle (mais du flask irait probablement aussi bien pour ça, voire du WSGI brut) propulsée par bjoern.
Clairement le rust optimisé fait mieux, le contraire m'aurait fortement déçu !
[^] # Re: Python, bottle, bjoern
Posté par Yth (Mastodon) . En réponse au journal TapTempo du Web en SQL avec SQLPage. Évalué à 4.
Alors les logs, j'avoue, j'ai pas trop d'idée de comment les rajouter avec bjoern, et je ne sais pas quel délais en plus ça prendrait...
J'ai codé un truc à l'arrache non optimisé, et je tombe à 9k req/sec.
Donc j'ai testé le bouzin en conditions un peu plus réelles sur un Odroid XU4, ARM, soft float (ça fait des années que je dois le réinstaller en HF), 8 cœurs, limités à 500Mhz pour cause de surchauffe (le ventilo est pété, la pâte thermique mérite d'être remplacée), python 3.7, à travers le réseau (gigabit, en câble pas en wifi), test ab depuis ma machine perso.
700 req/s.
Bon, OK, je libère le CPU 2 minutes en espérant qu'il ne crashe pas : 4x1.4Ghz et 4x2Ghz.
1800 req/s.
À noter que si je passe à 20 connexions en parallèle, on monte à 3300 req/s, parce qu'on a la latence réseau à prendre en compte, et 8 coeurs en face, donc pour les surcharger, 10 connexions parallèles ne suffisent pas.
On monte même à 3500 avec 100 requêtes parallèles, alors que en local ça ne changeait rien de monter au delà de 10.
Bon, voilà, à moins de trouver autre chose que je ne connais pas, je ne ferais pas mieux en Python sur ma machine.
J'avais testé plusieurs serveurs python derrière un apache ou un haproxy en mode load-balancer, d'autres backends que bjoern (waitress est pas mal par exemple), sur un autre projet qui consistait à servir une image aléatoire dans une liste à chaque requête. L'idée était de les précharger en python au début, avec le type, la taille et le contenu, et de servir les headers direct, et le contenu, sans jamais relire sur le disque.
On a exactement les mêmes perfs que la simple redirection, 13-14k req/s, avec des icônes, donc de petites images.
J'ai jamais réussi à faire mieux en python qu'une app bottle (mais du flask irait probablement aussi bien pour ça, voire du WSGI brut) propulsée par bjoern.
Clairement le rust optimisé fait mieux, le contraire m'aurait fortement déçu !