UPD. Testen der REST-API auf Golang. 120 000 [# / sec] ist nicht die Grenze?

Ich habe einen nicht sehr positiven Vergleich von Java mit GO festgestellt . Testen durch eine große Anzahl von Benutzern .

Ich beschloss zu prüfen, ob mit Go alles so rosig ist.
Mit Blick auf die Zukunft kann ich sagen, dass ich beim Zwischenspeichern im Speicher und beim Erstellen von JSON im laufenden Betrieb bis zu 120.000 [# / s] auf 8 physischen Kernen erreicht habe.

Grundlegendes GET-Anforderungsskript:

• Wenn die Daten im In-Memory-Cache gefunden werden und gültig sind, bilden wir JSON aus der Struktur
• Wenn sich keine Daten im Cache befinden, suchen wir sie in Bolt DB. Wenn wir sie finden, lesen wir den fertigen JSON
• Wenn in Bolt DB keine Daten vorhanden sind, fordern wir sie aus der Datenbank an und speichern sie im In-Memory-Cache
• Die Daten im speicherinternen Cache werden im Pufferkanal akkumuliert. Nach der Akkumulation von etwa 10.000 Elementen werden sie durch einmaliges Speichern in Bolt DB zurückgesetzt
• Wenn sich die Daten in der Datenbank geändert haben (Aktualisieren / Einfügen), wird eine Benachrichtigung über pg_notify übertragen und die Daten im Cache werden als ungültig markiert. Beim nächsten Lesen werden sie erneut aus der Datenbank gelesen

Unter den Schnitttestergebnissen und dem Code des Prüfstands GitHub

Update 05/06/2020

Es bestand die Möglichkeit, in der Oracle-Cloud zu testen .

• Der Stand ist auf 3 Servern aufgebaut - 8 Core Intel (16 Virtual Core), 120 Memory (GB), Oracle Linux 7.7
• NVMe — 6.4 TB NVMe SSD Storage min 250k IOPS (4k block)
• — 8.2 Network Bandwidth (Gbps)
• PostgreSQL — 16 000 [get/sec], oncurrency 1024, 60 [ms]. Get 360 000 000 . JSON 1800 .
• — 100 000 — 120 000 [get/sec], oncurrency 1024, 2 [ms].
• PostgreSQL — 10 000 [insert/sec].
• 2 4 8 Core, .

• JSON Bolt DB 2 HDD, SSD
• PostgreSQL HDD SDD 100
• Bolt DB SDD HDD 100
• JSON " " 10 PostgreSQL SDD
• — Failed requests Concurrency 16 384

,
— GitHub. 4000 , .

, JSON encoder/decode — JSON 2 .

HTTP Get handler JSON

BenchmarkHandler_DeptGetHandler-2         1000000          41277 ns/op     4845.26 MB/s        10941 B/op          259 allocs/op

HTTP Get handler francoispqt/gojay

BenchmarkHandler_DeptGetHandler-2         1000000          13300 ns/op     15036.97 MB/s         3265 B/op           11 allocs/op

:

• PostgreSQL 11 Windows 10, — 30 .
• — 10 000 000 , 100 000 000 .
• JSON 1500 , 1 10 .
• — core i7-3770 — 4 core (8 thread), 16 , HDD (WD 2.0TB WD2000fyyz), SSD (Intel 530 Series).
• ApacheBench, concurrency level 1 4096, 1 000 000 .
• Windows, .
• RAID . .

:

• GET PostgreSQL — HDD ( , JSON ).
• GET PostgreSQL — SSD ( , JSON ). SSD
• GET BOLT DB — HDD (JSON BOLT DB)
• GET BOLT DB — SSD (JSON BOLT DB)
• GET (JSON )

Concurrency Level , ApacheBench " ".

GET PostgreSQL — HDD ( )

GET PostgreSQL — SSD ( )

GET BOLT DB — HDD (JSON BOLT DB)

GET BOLT DB — SSD (JSON BOLT DB)

GET

Oracle

Oracle 3- :

• VM.DenseIO2.8 — 8 Core Intel (16 virtual core), 120 Memory (GB), Oracle Linux 7.7
• NVMe — 6.4 TB NVMe SSD Storage (1 drives) min 250k IOPS (4k block)
• — 8.2 Network Bandwidth (Gbps)
• — PostgreSQL 12. .
• ApacheBench:
  
  • concurrency level 4 16384
  • 10 000 1 000 000 .
  • 2 8 ApacheBench ( ab 1 )

GET

• JSON — 1800 . Dept 10 Emp.
• Dept — 33 000 000, Emp — 330 000 000 .

:

• GET PostgreSQL
• GET JSON BBolt ( 74 )
• GET ( map)

.

Requests per second Concurrency.

Time per req. [ms] Concurrency ( ).

99% percentile [ms] Concurrency.

99% percentile [ms] Concurrency ( ).

backend 100 000 [#/sec] BBolt (oncurrency 128).
1600% , 1464%.
/ NVMe 0,02 [ms] (500 000 IOPS).

Benchmark, HTTP Get handler 13300 ns

BenchmarkHandler_DeptGetHandler-2         1000000          13300 ns/op     15036.97 MB/s         3265 B/op           11 allocs/op

ApacheBench, mean — 0.088 ms.
0.088 — 0.013 = 0.055 ms.
—

:

• net/http.(*conn).serve — (61.85%)
• net/http.(*connReader).backgroundRead — (7.04%)
• runtime.gcBgMarkWorker — (18.30%)

HTTP server (61.85%):

• — net/http.(*conn).readRequest — (9.29%). .
• — net/http.(*response).finishRequest — (21.74%). .
• — net/http.(*ServeMux).ServeHTTP — (23.33%).

readRequest, finishRequest backgroundRead (39.66%), IO Windows — internalpoll.(ioSrv).ExecIO — (24.78%).

Mal sehen, was unser Haupt-net / http. (* ServeMux) .ServeHTTP-Handler getan hat:

• URL-Analyse und Parameterverarbeitung - github.com/gorilla/mux.(*Route).Match - (2,29%)
• Generieren von JSON aus einer Struktur im Speicher - github.com/francoispqt/gojay.marshal - (9,92%)
• Arbeiten mit dem Cache im Speicher - (4,53%)