En regardant les résultats ci-dessous, un tel débit sort-il vraiment dans un environnement de CPU et de mémoire limités? J'ai pensé, en utilisant Docker pour Mac, j'ai essayé de vérifier quel type de résultat serait obtenu dans l'environnement Kubernetes. https://github.com/networknt/microservices-framework-benchmark/blob/master/README.md
Cette fois, le but est de confirmer la différence de vitesse de réponse et de débit avec la même limite de ressources appliquée. Les empreintes CPU et mémoire de chaque framework seront optimisées séparément, elles ne sont donc pas prises en compte dans ce résultat de vérification. Aussi, si j'ai le temps, je pense à enquêter dans l'environnement GKE.
Afin de rendre cette vérification facile à reproduire, le fichier manifeste Dockerfile et Kubernetes, une fois en conteneur, sont tous stockés dans le référentiel GitHub.
Chargez le service cible à partir du conteneur de chargement wrk.
Toutes les charges sont données via le service. Changez le pod qui fournit réellement la charge avec le service.
L'outil qui donne la charge utilise wrk et implémente comme suit
wrk
$ wrk -t4 -c64 -d60s http://microservice.default.svc.cluster.local:30000/ --latency
Etant donné que la surcharge de la partie de préchauffage est ignorée, la commande ci-dessus est exécutée deux fois et le résultat de la deuxième mesure est traité comme un résultat valide.
De plus, le conteneur à mesurer est mesuré avec les ressources suivantes données et un pod est démarré.
resource
resources:
requests:
cpu: 200m
memory: 400Mi
limits:
cpu: 200m
memory: 400Mi
De plus, le fichier manifeste Dockerfile et Kubernetes lorsqu'ils sont conteneurisés sont tous https://github.com/h-r-k-matsumoto/microservices-framework-benchmark Il est stocké dans le référentiel de. Les applications Java sont conteneurisées à l'aide de jib. Et il est basé sur jdk10. C'est parce que jdk8 n'optimise pas le nombre de threads comme indiqué ci-dessous. https://qiita.com/h-r-k-matsumoto/items/17349e1154afd610c2e5
Les 6 éléments suivants qui me tiennent à cœur sont ciblés.
| Cadre | débit(req/min) | moyenne(ms) | 90%LINE（ms） | 99%LINE（ms） |
|---|---|---|---|---|
| light-4j | 295,125 | 29.35ms | 72.17ms | 99.01ms |
| go-http | 163,557 | 48.11ms | 119.78ms | 304.28ms |
| iris | 143,173 | 66.62ms | 174.93ms | 571.83ms |
| spring-boot2-undertow | 107,540 | 46.04ms | 94.61ms | 196.11ms |
| spring-boot2-tomcat | 38,068 | 117.01ms | 290.70ms | 492.55ms |
| helidon-se | 30,742 | 160.51ms | 299.11ms | 969.99ms |
** light-4j était certainement explosif. ** ** Cependant, la différence de vitesse n'était pas aussi grande que sur le site d'origine.
Compte tenu de l'opération réelle, il est nécessaire de considérer l'API dans JSON et gRPC. La vérification de cette partie doit également être envisagée.
Puisqu'il n'a pas été possible de désactiver le système d'échange avec Docker pour Mac, je voudrais procéder à la vérification même dans l'environnement GKE.
Il est difficile de changer le cadre en light-4j, mais au moins je veux le changer en spring-boot2-undertow.
La méthode d'exécution est https://github.com/h-r-k-matsumoto/microservices-framework-benchmark/blob/fix/master/k8s_reproduce_benchmark/DockerForMac.md Veuillez confirmer.
Après cela, en termes de light-4j, kubernetes a de mauvaises performances, donc je pense que c'est un arrêt. https://gitter.im/networknt/light-4j?at=5bf5948a958fc53895c9dbe5