КМ
а вы пытались выяснить почему именно там скоростью не пахнет?
если честно, не знаю в какую сторону копать
Size: a a a
2020 April 29
КМ
допвстим, локальные тесты показывают вот такую картину:
DP
так это, профайлить пора. ну, после того, как будет решена проблема time_wait
КМ
суть в том, что это голая работа fasthttp
MM
Грпс поддерживает?
Ну в общем, я не дочитал...😕
The protoc-gen-go plugin in this module is now a thin wrapper over the protoc-gen-go plugin in the google.golang.org/protobuf module. As a result, there are many changes to the generated code.
DP
а, если коротко, что хорошего обещают?
может, и мне пора перекатиться?
может, и мне пора перекатиться?
MM
а, если коротко, что хорошего обещают?
может, и мне пора перекатиться?
может, и мне пора перекатиться?
Из основных, добавили пакет reflect, dynamicpb для реализации dynamic message type и в новом пакете protojson зафиксили ряд проблем связанных с jsonpb.
MM
а, если коротко, что хорошего обещают?
может, и мне пора перекатиться?
может, и мне пора перекатиться?
Может быть чего-то еще, я сильно не углублялся)
p
Всем привет! Такой вопрос, решили на Го написать быстрый обработчик метрик в веба с использованием fasthttp. Суть простая - максимально быстро принять http коннект, взять данные, слить в канал и освободить коннект. Далее на фоне уже из канала в горутине забирать данные и отправлять пачками в базу. Прототип написали, и вроде, как все работает. Но проблема в другом, мало того, что скоростью тут и не пахнет, так еще и после обратки http запроса, каждый из них на уровне OS - уходит в time_wait. Естественно, через некоторое время большинство новых коннектов получают на своей свотроне - Connection reset by peer ибо в системе закончились сокеты, конечно, сколько-то там попадает, когда часть time_waitов умирает. Может у кого есть мысли, как реализоваться максимально конкуретный прием на fasthttp?
канал буферизованный?
КМ
конечно
КМ
а точнее, используется несколько каналов
КМ
с разной величиной и временем слива в базу
КМ
а залив идет через select
MM
а, если коротко, что хорошего обещают?
может, и мне пора перекатиться?
может, и мне пора перекатиться?
Но с версиями они конечно намутили, новая APIv2 зависит от старой APIv1. И новый плагин, пока что не поддерживает gRPC, поэтому используется старый для генерации.
DP
из списка изменений мне очевидно, что мне оно не надо
DP
так что не помогу вам ничем :)
КМ
так это, профайлить пора. ну, после того, как будет решена проблема time_wait
(pprof) top
Showing nodes accounting for 2250ms, 78.95% of 2850ms total
Dropped 67 nodes (cum <= 14.25ms)
Showing top 10 nodes out of 138
flat flat% sum% cum cum%
1100ms 38.60% 38.60% 1100ms 38.60% syscall.Syscall
470ms 16.49% 55.09% 510ms 17.89% syscall.Syscall6
340ms 11.93% 67.02% 340ms 11.93% runtime.epollctl
60ms 2.11% 69.12% 60ms 2.11% runtime.epollwait
60ms 2.11% 71.23% 60ms 2.11% runtime.futex
50ms 1.75% 72.98% 1830ms 64.21% github.com/valyala/fasthttp.(*workerPool).workerFunc
50ms 1.75% 74.74% 50ms 1.75% runtime.memmove
40ms 1.40% 76.14% 1050ms 36.84% github.com/valyala/fasthttp.(*Server).serveConn
40ms 1.40% 77.54% 40ms 1.40% github.com/valyala/fasthttp.stringContainsCTLByte
40ms 1.40% 78.95% 40ms 1.40% indexbytebody
DP
похоже - надо просто расширять кластер
DP
хотя - нарисуйте граф, возможно - эти сисколы не сетевой ввод-вывод
