Wenn man sich die Ergebnisse unten ansieht, kommt ein solcher Durchsatz wirklich in einer Umgebung mit begrenzter CPU und begrenztem Speicher heraus? Ich dachte, ich habe mit Docker für Mac versucht zu überprüfen, welche Ergebnisse in der Kubernetes-Umgebung erzielt werden. https://github.com/networknt/microservices-framework-benchmark/blob/master/README.md
Dieses Mal besteht der Zweck darin, den Unterschied in der Antwortgeschwindigkeit und im Durchsatz bei gleichem angewendeten Ressourcenlimit zu bestätigen. Die CPU- und Speicher-Footprints jedes Frameworks werden separat optimiert, sodass sie in diesem Überprüfungsergebnis nicht berücksichtigt werden. Wenn ich Zeit habe, denke ich auch darüber nach, in der GKE-Umgebung nachzuforschen.
Um die Reproduktion dieser Überprüfung zu vereinfachen, werden die Manifestdateien Dockerfile und Kubernetes im Container alle im GitHub-Repository gespeichert.
Laden Sie den Zieldienst aus dem Ladecontainer wrk.
Alle Lasten werden per Service gegeben. Schalten Sie den Pod, der die Last tatsächlich liefert, mit Service.
Das Werkzeug, das die Last angibt, verwendet "wrk" und implementiert Folgendes
wrk
$ wrk -t4 -c64 -d60s http://microservice.default.svc.cluster.local:30000/ --latency
Da der Overhead des Aufwärmteils ignoriert wird, wird der obige Befehl zweimal ausgeführt und das Ergebnis der zweiten Messung als gültiges Ergebnis behandelt.
Zusätzlich wird der zu messende Behälter mit den folgenden angegebenen Ressourcen gemessen und ein Pod gestartet.
resource
resources:
requests:
cpu: 200m
memory: 400Mi
limits:
cpu: 200m
memory: 400Mi
Darüber hinaus sind alle Dockerfile- und Kubernetes-Manifestdateien im Container enthalten https://github.com/h-r-k-matsumoto/microservices-framework-benchmark Es wird im Repository von gespeichert. Für Java-Anwendungen verwenden wir jib, um Container zu erstellen. Und es basiert auf jdk10. Dies liegt daran, dass jdk8 die Anzahl der Threads nicht wie unten gezeigt optimiert. https://qiita.com/h-r-k-matsumoto/items/17349e1154afd610c2e5
Die folgenden 6 Punkte, die mir persönlich wichtig sind, sind zielgerichtet.
| Rahmen | Durchsatz(req/min) | durchschnittlich(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 war sicherlich explosiv. ** **. Der Geschwindigkeitsunterschied war jedoch nicht so groß wie auf der ursprünglichen Website.
In Anbetracht des tatsächlichen Vorgangs muss die API in JSON und gRPC berücksichtigt werden. Die Überprüfung dieses Teils sollte ebenfalls in Betracht gezogen werden.
Da es nicht möglich war, das Swap-System mit Docker für Mac zu deaktivieren, möchte ich die Überprüfung auch in der GKE-Umgebung fortsetzen.
Es ist schwierig, das Framework auf Light-4j zu ändern, aber zumindest möchte ich es auf Spring-Boot2-Sog ändern.
Die Ausführungsmethode ist https://github.com/h-r-k-matsumoto/microservices-framework-benchmark/blob/fix/master/k8s_reproduce_benchmark/DockerForMac.md Bitte bestätigen.
Danach hat kubernetes in Bezug auf light-4j eine schlechte Leistung, daher denke ich, dass es ein Stopp ist. https://gitter.im/networknt/light-4j?at=5bf5948a958fc53895c9dbe5