Notei uma comparação não muito positiva de Java vs GO. Teste por um grande número de usuários .
Decidi verificar se tudo está tão bem com o Go.
Olhando para o futuro, direi que, ao armazenar em cache a memória e criar JSON em tempo real, consegui obter até 120.000 [# / seg] em 8 núcleos físicos.
Script básico de solicitação GET:
- Se os dados forem encontrados no cache de memória e forem válidos, formaremos JSON a partir da estrutura
- Se não houver dados no cache, procuramos por eles no Bolt DB; se os encontrarmos, leremos o JSON finalizado
- Se não houver dados no Bolt DB, solicitá-los do banco de dados, salvá-los no cache da memória
- Os dados no cache da memória são acumulados no canal do buffer. Após o acúmulo de cerca de 10.000 elementos, eles são descartados como um único salvamento no Bolt DB
- Se os dados no banco de dados foram alterados (atualização / inserção), uma notificação é enviada via pg_notify e os dados no cache são marcados como inválidos; na próxima vez que forem acessados, serão lidos novamente no banco de dados
Sob os resultados do teste de corte e o código do banco de testes GitHub
Atualização 05/06/2020
Houve uma chance de testar na nuvem Oracle .
- o suporte é montado em 3 servidores - 8 núcleos Intel (16 núcleos virtuais), 120 memória (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 . .
:
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%).
Vamos ver o que nosso principal manipulador net / http. (* ServeMux) .ServeHTTP fez:
- Análise de URL e processamento de parâmetros - github.com/gorilla/mux.(*Route).Match - (2,29%)
- Gerando JSON a partir de uma estrutura na memória - github.com/francoispqt/gojay.marshal - (9.92%)
- Trabalhar com cache na memória - (4,53%)
