.Net GRPC, или мульти-стек в проекте

[Kerman]

-пакеты по 320 байт

То есть вы взяли gRPC/protobuf, только чтобы кидаться бинарными пакетами по 320 байт? Странное решение.

Тут бы подошёл обычный советский TCP. Отключаем Nagle (NoDelay = true) и вперёд кидаться друг друга пакетами практически безлимитно.

Протобуф - он какбы не для этого. Это суровый сериализатор сложных структур. И он отлично и быстро работает. Но вам он зачем? Если нет структуры - не нужен и сериализатор.

[Mihail37]

Не совсем так. Голый TCP - это стандарт Asterisk а, и мы должны были его придерживаться только в первой точке в цепочке по работе с голосом, которая взаимодействует именно с Астером. Далее - по GRPC цепочке - пакеты можно было укрупнять и обогащать, увеличивая задержки + появляются сквозные идентификаторы, признаки попутного анализа пакетов голоса (например, есть ли в них речь или пакет пустой), те в структуре GRPC пакетов уже не только голые аудио-байты. К тому же же yandex-speech-recognition или text-to-speech работают по протоколу GRPC.

[Kerman]

Вам бы неплохо было бы определиться с требованиями к системе. gRPC работает через протобуф, протобуф - через https. Последний работает через TCP. Угадайте, включен ли у него алгоритм Нагла? Спойлер - он включен у всех по умолчанию. Соответственно, у вас будут задержки, лишние буфферы, лишний расход цпу. Если вас задержки не устраивают, то у вас путь один - к TCP. Это не значит, что нельзя "обогащать пакеты". Можно и ещё как. Простую информацию можно встраивать прямо в пакет (ну кто запретит пару байт с флагами вписать?), сложную и несинхронную оставить на gRPC.

[Mihail37]

Все же хочется снизить риск человеческих ошибок при разборе голых байт, и в принципе использовать более удобные инструменты если нет противопоказаний к обратному.

Тут скорее вопрос к реализации сетевого стека в части GRPC на .net под Linux, если при прочих равных такое же решение на GO прекрасно едет.

Так как в реальном проекте главное - это именно решить проблему, с гарантией, что лучше чем пытаться тюнить текущий стек «на костылях». Хотя именно в .Net такую критику - что "вы не умеете его готовить" - по данной проблеме, встречаю постоянно)

[Kerman]

Я не знаю, почему у вас не едет дотнет под линукс. Я давно и плотно работаю с gRPC и у меня всё прекрасно едет. Что дотнет, что линукс, что gRPC - технологии, отлаженные годами. И это мейнстрим. И я сильно сомневаюсь, что в их связке есть какие-то проблемы. И я сильно сомневаюсь, что Го намного быстрее. Скорее всего вы умалчиваете какой-то интересный факт, а может и не заметили что-то.

Хотя именно в .Net такую критику - что "вы не умеете его готовить" - по данной проблеме, встречаю постоянно)

Я вам то же самое скажу. Вы не умеете его готовить. Прекрасно работает под большими нагрузками. В том числе и под линуксом.

[Mihail37]

Могу добавить что информация актуальна на конец 2022, может быть в .Net 8 - более стабильной мажорной версии - это поведение поменялось в лучшую сторону.

PS помню еще .net 5, где попытки обратиться к GRPC-стриму, который был переведен в Dispose состояние (программистские ошибки, да), но все же такой баг в коде приводил к дедлокам на уровне платформы и stopper-у всего приложения.

Так что в те времена складывалось впечатление о "сырости" .net-ного GRPC.

[Kerman]

В конце 22го был уже .NET 6. Который LTS. И я на нём строил сервер для приложения на основе gRPC/protobuf. Под линуксом, да. И работал он прекрасно, полностью выжимая канал. Без перерасходов памяти, без сильной нагрузки на cpu. Без дедлоков. Хотя я не пробовал никогда лезть в задиспоженый стрим. Это как-то странно.

По мотивам той системы я уже писал статью на хабре.

Так что не знаю. Похоже, у нас разные дотнеты, разные линуксы и разные gRPC.

[Prikalel]

[posledam]

Понятно, хоть и бюджет значительно вырос, но грамотный архитектор крикнул "все на Go", а там всё как залетало. Очень интересная и поучительная история. Жаль конечно, что не разобрались, в чём же конкретно причина, именно это в статье и хотелось узнать. Ну хотя бы какие попытки были, что делали, как делали.

А если завтра решение на Go барахлить начнёт, дальше куда? На Rust? :)

[Mihail37]

Если кратко, то инструментальные измерения деградации показывали длительное время на операциях чтения/записи при получении/отправке пакетов из/в сеть на больших RPS (расчеты приводил выше).