ничего умного - померять разницу в скорости goswagger кодагена и чистого анмаршала в структуру...
goswagger использует встроенные json?

да

Господа, подскажите пожалуйста, можно ли через gRPC стрим передавать данные в структурированном сообщении?

То есть, у меня есть вот такой сервис

rpc SaveCustomFile(stream SaveCustomFileRequest) returns(SaveCustomFileResponse) {}

И вот такой тип входящего стрима

message SaveCustomFileRequest {
    string name = 1;

         … еще какие-то плоские поля

    bytes data = 100500;
}



Нужно ли на сервере в цикле читать, или нет?
Если в цикле, то как быть с остальными полями? Они на каждой итерации будут приходить?

Тестирую через BloomRPC, отправляю массив байтов, но на сервер приходит Data = nil

но какой смысл в этих измерениях?

rpc SaveCustomFile(stream SaveCustomFileRequest) returns(SaveCustomFileResponse) {}

message SaveCustomFileRequest {
    string name = 1;

         … еще какие-то плоские поля

    bytes data = 100500;
}

каждый раз будет приезжать SaveCustomFileRequest целиком, да

и да, в цикле

То есть все будет приезжать целиком, а в Data будет следующий чанк?

если он использует встроенный, то наверно понятен результат и смысла особого нет... но... почему бы не поиграться.
тем более, что я сам (лично) так goswagger и не использовал пока.

ну вот разве что - научиться госваггеру

вообще - встроенный json тормоз и жрун проца

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

по умолчанию да, но на модели легко накладывается генерация из easyjson или ему подобных

в моём случае есть...
мне очень нужна производительность http микросервисов помноженная на удобство документирования api...
небольшой выигрышь в 10% на 300 серверах выходит в 30 серверов...

ничего себе у вас нагрузки

есть такое... приходится считать деньги на трудозатраты vs сервера... в нашем случае не всегда дешевле залить серваками :)

приходите - поработаем, у нас вакансии есть...

Главное только лечить больное место, а не все подряд. Сначала запрофилировать сервис, найти что именно тормозит, и потом его чинить.

это вы правы, но у меня довольно толковые ребята и куча мониторинга, детские болячки редки...
в нашем случае большая часть изменений ведущих к увеличению нагрузки оправданы - сложнее правила обработки, больше правил...
но так как кол-во данных и серверов большое, то приходится бережно относится и к инфраструктурным частям системы (протоколам и т.п...)

Профилирование как раз лечит сложные проблема, которые под хорошими нагрузками всплывают.
Например, както выяснил что в проекте больше всего логгер тормозит или шаблонизатор, хотя народ крутил базу данных.
А так переход php -> go и в 3 раза меньше серверов надо - это норма 😂

» А так переход php -> go и в 3 раза меньше серверов надо - это норма 😂
у нас, кстати, go либо новые вещи с нуля, либо как раз заменил php (и продолжает)

но насчёт замена меньше серверов... это не всегда так, php может работать ничуть не медленнее, а то и быстрее :) если он вызывает исключительно библиотечные отлаженные временем функции (json/regexp/...)...

Коллеги, сделавшие пхп/го Франкенштейна, считают, что одним пхп уже не прожить
https://habr.com/ru/post/495224/
Как я понимаю, это го, только с парсером на пхп.

У пхп вебприложения изначально проблемны - на каждый запрос порождается процесс. Даже если не порождается, то берется из пулла и нет разделения памяти. Бессмысленные операции копирования данных от запроса к запросу.
Чтобы этого избежать, надо забить на php-fpm и сделать постоянно работающих демонов, которые не будут умирать или чистить память на каждый запрос, а запросы им поставлять через очередь. Все это такие пляски с бубнами...
Плюс параллельность, которой нет. Последнее приложение с параллельностью, которое писал, было на форках, те копировало само себя в памяти. Можно представить, сколько это занимало памяти. Да, в пхп есть расширение pthread, но оно недоступно как раз вместе с php-fpm, а мутить демоны я тогда ещё не умел 😂

всё так, но есть 2 варианта когда вам без php не обойтись....