На глаза попалась не особо позитивное сравнение Java vs GO. Тестирование большим числом пользователей.

Решил сам проверить, действительно ли так все не радужно с Go.
Забегая вперед скажу, что при кэшировании в памяти и формировании JSON "на лету" удалось получить до 56000 [#/sec] на 4 физических ядра.

Базовый сценарий GET запроса:

• Если данные найдены в in memory кэше и они валидные, то формируем JSON из структуры
• Если данных в кэше нет, то ищем их в Bolt DB, если находим, то считываем готовый JSON
• Если данных нет в Bolt DB, то запрашиваем их из БД, сохраняем их в in memory кэше
• Данные в in memory кэше накапливаются в буферном канале, после накопления около 10000 элементов они сбрасываются единым save в Bolt DB
• Если данные в БД менялись (update / insert) то через pg_notify передается уведомление и данные в кэше помечаются как невалидные, при следующем обращении они считываются заново из БД

Ни каких RAID не использовалось. Интересно было замерить максимальные показатели на одном диске.
Краткие выводы:

• использование кэширования JSON в Bolt DB дает прибавку в скорости примерно в 2 раза как на HDD, так и на SSD дисках
• перенос БД PostgreSQL с HDD на SDD дает прибавку минимум в 100 раз
• перенос Bolt DB на SDD с HDD так же дает прибавку минимум в 100 раз
• кэширование структуры в памяти и формирование JSON "на лету" дает прибавку в 10 раз по сравнению с БД PostgreSQL на SDD
• стабильность отличная — ни каких Failed requests вплоть до 4096 одновременных подключений.

Под катом результаты тестирования, и код тестового стенда GitHub

Результаты тестирования, доступны по ссылке
Кому интересен код тестового стенда — добро пожаловать на 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, перед каждым тестом машина перегружалась.

В ходе тестирования проверялись следующие граничные случаи:

• 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 с кэшированием структуры в памяти

Профилирование

По данным 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%).

Посмотрим чем занимался наш основной обработчик net/http.(*ServeMux).ServeHTTP:

• Парсинг URL и обработка параметров — github.com/gorilla/mux.(*Route).Match — (2.29%)
• Формирование JSON из структуры в памяти — github.com/francoispqt/gojay.marshal — (9.92%)
• Работка с кэшем в памяти — (4.53%)