Bonjour à tous, je viens de faire aujourd'hui une expérience afin de valider un socle pour des microservices

Pour ce faire, j'ai réalisé un démonstrateur très bête, déployé sur mon kube, ce dernier reçoit un payload qui est une requête sql, et donne la réponse json de cette requête au travers de 4 services

- L'un en nginx + php/fpm avec opcache, 24 process fixes ( correspondant aux nombres de coeurs de cpu )
- L'un en pur php, avec 24 process php lancés via php -S
- L'un en php tournant via un serveur http lancé par openswoole
- L'un en go

Du coup les résultats sont excessivement proches, à peu près 10 secondes avec variation max de 1sec pour 10000 requêtes avec une concurrence de 200 d'entre elles ( sinon parfois ça pête sur le go .. )

Je me dis que mon analyse n'est pas pertinente car le bottleneck au final , c'est le serveur sql, et qu'au final il n'existerait pas vraiment de saint graal du microservice répondant 2 fois plus rapidement que les autres .. Tout serait question de code potentiellement mal foutu ( genre un orm typant toutes les rows à retourner ) ou de logique métier qui pourrait prendre du temps dans le backend

Qu'en pensez-vous ?

Merci pour vos précieuses lumières  

Difficile de répondre sans plus d’informations mais si le bottleneck c'est le serveur sql, et ce qu'a y pas moyen d'avoir du cache (redis ou autre) sur les requêtes potentiel et leur retour ?
Tu gagneras sans doute plus sur ce genre de truc (si la ram et la diversité des requêtes le permettent) que de comparer les process php...