какая разница, бинарные, или нет
Да по сути не суть, согласен. Я больше 15к тпс не смог выжать на хендлинге. Сишная реализация даёт 100к
Nik
Daniel
а?!
Nik
там, где анмаршалинг - там же switch и вызов нужной функции
А как смотреть в нужную функцию? Если делать map на функцию, память течет
Daniel
я же говорю - switch
Daniel
может быть - type switch
heavycharged
с обработкой ошибок все довольно неприятно. собственно, все, что можно с ошибкой сделать - это ее залогировать и вернуть
Да я тут пишу API, и уже подустал честно говоря делать эти проверки.
Частенько забываю сделать return, код начинает делать то, чего делать не должен. Думаю было бы удобно присобачить что-то вроде
if err != nil {
return ctx.WithError(err).Exit()
}
а внутри уже чекаем на ошибки, логируем, ещё бы cancel в самом контексте был, его бы дернуть, а сам вызов Exit() возвращает http.Handler в зависимости от ошибки, ещё бы классно знать, если допустим пришел запрос AJAX, то пишем во Writer JSON объект, а если запрос обычный (не XMLHttpRequest), тогда какую-то страницу с ошибкой. Короче, думаю как присобачить, и не могу придумать пока что. Ещё бы классно эту всю хрень складывать в пул когда она не нужна, чтобы GC не напрягать особо.
Nik
А как расширять вшытиый свич мне что то в голову не приходит
Daniel
никак
Nik
(для map обертку сделал с добавлением хендлера, она вполне понятна)
Daniel
но и протокол расширять тоже вроде никак, правда?
Nik
а протокол расширять и не надо.
Daniel
тогда и свитч расширять не надо
Nik
надо просто что бы либа читала, анмашрашила, и позволяла добавлять кастомные хендлеры
Daniel
а!
Daniel
так это
Daniel
заводишь сколько надо переменных соответствующего типа, и присваиваешь хендлеры им
Nik
(я для оптимизации на хедлере даже не занимаюсь полным анмаршалом, только определнные байты. Анмаршал идет уже в хендлере полный)
Nik
заводишь сколько надо переменных соответствующего типа, и присваиваешь хендлеры им
типа либа допускает 10 хендлеров. Хочешь юзай, хочешь не юзай
Daniel
ага
Nik
ну эт уже что то не то(((
Nik
должно же быть что то более прямое
Daniel
ну эт уже что то не то(((
ну вот такое у нас ООП. на самом деле - это не плохо, просто непривычно
Daniel
нет, не должно
Daniel
статическая типизация - она статичиская и есть
Daniel
расширение реализации у нас тут не предполагается неявное (и это специально. я недавно мнооого с++ прочел, чуть не опух. реально расследование кажды раз чтобы понять, какой именно код отрабатывает)
Nik
Да не в типизации же проблема тут
Daniel
смотрите
Daniel
мапа ваша - это шаг в сторону динамической типизации
Nik
я сильно огорчалися, что func:=map[string]fucn() под нагрузкой съело все озу
Daniel
а динамическая типизация - это как раз то, от чего мы хотим избавиться
Daniel
потому, что заебались уже
Nik
тогда вместо либы делать просто рыбу приложухи, и каждый раз на нее натягивать новый функционал.
Nik
и тут при обновлении протокола будет ад
Daniel
типа того
Nik
но мы статике - и не надо менять протокол)
Daniel
есть swagger, есть protobuf
Daniel
и оба они одинаково примерно устроены
Nik
там кастом, 64байта заголовок, в котом указано сколько байт следом данные.
Nik
совсем кастом.
Daniel
описание протокола, генерация кода, переменные для хендлеров
Daniel
и это настоящий go way
Daniel
и вам я советую сделать так же
Nik
сходу весь продакшн на goway не утащишь. Надо сначала показать, что это проще сей и работает так же быстро.
Nik
Иначе мне скажут что я дурачек с горы)
Daniel
там кастом, 64байта заголовок, в котом указано сколько байт следом данные.
у меня заголовок был 4 байта :) тип сообщения, и про него было уж известно, какой оно длины
Nik
Nik
и нагрузки безумнейшие
Daniel
безумнейшие - это сколько?
Nik
и еще и асинхрон(в рамках которого светит sync.Map)
Daniel
зачем?
Daniel
нахера?
Daniel
это не много, прям скажем
Nik
потому что общей нагрзуки еще больше
Daniel
а это надо руки повыпрямить слегка :)
Nik
я посмотрю, сколько смогу еще выжать без него.
Daniel
сходу весь продакшн на goway не утащишь. Надо сначала показать, что это проще сей и работает так же быстро.
вот тут интересно. это не проще сей. паттерны те же самые используются. это безопаснее (нет переполнений и ликов). ну и многопоточность, конечно, попроще заюзать
Nik
И кстати, странная тема. Меняю буферы, и скорость обработки либо не меняется либо падает (буферы украл из сишной реализации)
eadConn.SetReadBuffer(1*1024*1024)
readConn.SetWriteBuffer(1*1024*1024)
readConn.SetNoDelay(true)
writeConn.SetReadBuffer(1*1024*1024)
writeConn.SetWriteBuffer(1*1024*1024)
writeConn.SetNoDelay(true)
Nik
вот тут интересно. это не проще сей. паттерны те же самые используются. это безопаснее (нет переполнений и ликов). ну и многопоточность, конечно, попроще заюзать
Проще в смысле быстрее выкатить реализацию на go, чем на сях. Сильно быстрее
G72K
Хотите быстрый разбор протокола - делайте кодогенерацию
G72K
Пока нормальное метапрограммирование не завезли других быстрых решений нет
G72K
Этот кусок я только собираюсь подсмотреть в понедельник
Посмотрите ещё на Kaitai Struct одним глазком хотя бы
Nik
Хедер статичен
Nik
За ним мапа стринг стринг
Nik
Разбор идет после хендлинга, на хендлере читаю только роут
Nik
Так что кологенерауия тут не причём
Wingman
почему может не отрабатывать defer?
Oleh
пробовали смотреть где узкие места через go tool pprof ?
G72K
Разбор идет после хендлинга, на хендлере читаю только роут
Вы же либу расширяемую пишите? Вот пусть это будет кодогенератор, кому на вход дают типы сообщений и коллбэки , внутри оно switch построит статический
Oleh
Вы же либу расширяемую пишите? Вот пусть это будет кодогенератор, кому на вход дают типы сообщений и коллбэки , внутри оно switch построит статический
мне аж стало интересно как так сделать, могли бы тыкнуть носом где можно почитать з примерами?
Nik
пробовали смотреть где узкие места через go tool pprof ?
Да. Из самого жирного - syscall на чтение запись 48%(это вроде хорошо). Потом фтючерсы, а дальше слабопонятро.