gRPC / rest запросы. Че за нах?

[OtherSide]

У меня сайтик разменял уже второй десяток, после взлома решил уж переписать все под современные фреймоврки.
Крутился еще на asp.net MVC5 переписал под свежий .net core 7

Заодно уж решил по модному сборщик данные из десктопного приложение с WCF переписать под микровервис. И походу эта хрень не взлетела! Локально все работает отлично, на продакшине - запросы приходят через 2-3-5-7 секунд. Потом все вообще валится. Хотя не такие уж и активные запросы то.
Сейчас другой сервис все отлично обрабатывает из тех же запросов с той же частотой к базе, а этот микросервис должен кеш отдавать. Медленно приходит именно запрос к сервису, сам код там простой и работает очень быстро.

Я очень слабо представляю как работают очереди запросов и все такое, думаю дай попробую на новомодный gRPC - там запрос стабильно отрабатывает 2 секунды - правда первый, дальше по 10 мс.
Но 2 секунды там на каждое создание канала! Не держать же его всегда открытым.

Че за нах вообще? Древний WCF отдавал все в XML и горя не знал, все из коробки работало. А тут непонятные пляски с бубном нужны

[iDesperado]

Недавно видел интересный батл, в итоге выяснилось что .net тормоз
https://dusted.codes/how-fast-is-really-aspnet-core

Но все же тысячи реквестов в секунду держит. Что такое у вас канал, коннект к базе?

[Next]

У меня сайтик разменял уже второй десяток, после взлома решил уж переписать все под современные фреймоврки.
Крутился еще на asp.net MVC5 переписал под свежий .net core 7

Заодно уж решил по модному сборщик данные из десктопного приложение с WCF переписать под микровервис. И походу эта хрень не взлетела! Локально все работает отлично, на продакшине - запросы приходят через 2-3-5-7 секунд. Потом все вообще валится. Хотя не такие уж и активные запросы то.
Сейчас другой сервис все отлично обрабатывает из тех же запросов с той же частотой к базе, а этот микросервис должен кеш отдавать. Медленно приходит именно запрос к сервису, сам код там простой и работает очень быстро.

Я очень слабо представляю как работают очереди запросов и все такое, думаю дай попробую на новомодный gRPC - там запрос стабильно отрабатывает 2 секунды - правда первый, дальше по 10 мс.
Но 2 секунды там на каждое создание канала! Не держать же его всегда открытым.

Че за нах вообще? Древний WCF отдавал все в XML и горя не знал, все из коробки работало. А тут непонятные пляски с бубном нужны

Подключите бесплатный app insights, отмониторьте запросы. Где-то оно затыкается. Дотнет очень быстрый. Могу предположить, что DI неправильно настроен, и он на каждом запросе создаёт пул подключений к БД.

[OtherSide]

Ошибка оказалось до смешного тупая. При портировании забыл прописать хеш функцию и там дикшинари из которого шел пул запросов разростался в геометрической прогрессии. .net core не причем.

Но все равно не снимается вопрос про grpc - тестировал hello world Из туториала - 2.3 секунды первый запрос!

[Next]

Но все равно не снимается вопрос про grpc - тестировал hello world Из туториала - 2.3 секунды первый запрос!

Warm-up. Компиляция кода, поднятие сервисов, инициализация ресурсов. Это нормально. Чтобы работало быстрее, нужно делать что-то вроде heartbeat.

[OtherSide]

Но все равно не снимается вопрос про grpc - тестировал hello world Из туториала - 2.3 секунды первый запрос!

Warm-up. Компиляция кода, поднятие сервисов, инициализация ресурсов. Это нормально. Чтобы работало быстрее, нужно делать что-то вроде heartbeat.

Как это вообще должно работать в концепции scope DI когда на каждый чих инициализация

[Next]

Но все равно не снимается вопрос про grpc - тестировал hello world Из туториала - 2.3 секунды первый запрос!

Warm-up. Компиляция кода, поднятие сервисов, инициализация ресурсов. Это нормально. Чтобы работало быстрее, нужно делать что-то вроде heartbeat.

Как это вообще должно работать в концепции scope DI когда на каждый чих инициализация

Аппа будет стартовать при первом вызове heartbeat, а потом находиться в активном состоянии. Т.е., всё уже будет проинициализировано.

[OtherSide]

Ну это получается только синглтон можно использовать, скоупы - нет

[Next]

Ну это получается только синглтон можно использовать, скоупы - нет

Если пулл коннекшенов, то он и должен быть синглтоном. А вообще, какой именно компонент вы используете? Мб там есть специальные методы инициализации, которые лишат вас головной боли.

[OtherSide]

Там и каждый отдельный вызов замрял - ну не так уж и быстро. Даммии заглушка выполнялась за 10-30 миллисекунд. На топовом железе. Не мгновенно как бы. По моему это вообще не быстрее обычных рест запросов.
В общем показаолось что эта штука еще очень сильно сырая, плюс весь этот гемор с генерацией файлов и использованием proto файлов - решил пока не для моих задач

[Next]

Там и каждый отдельный вызов замрял - ну не так уж и быстро. Даммии заглушка выполнялась за 10-30 миллисекунд. На топовом железе. Не мгновенно как бы. По моему это вообще не быстрее обычных рест запросов.
В общем показаолось что эта штука еще очень сильно сырая, плюс весь этот гемор с генерацией файлов и использованием proto файлов - решил пока не для моих задач

А можно поинтересоваться, что за виртуалка?
Просто, по идее, даже если это идет дамми запрос, то он проходит полный пайплайн дотнет кора (как и любой другой технологии), и на тощем железе оно в любом случае будет работать не молниеносно. Можете проверить на тех же java или nodejs. Быстрый отклик будет разве что у CGI, и то не факт, т.к. у провайдера услуг могут быть свои middleware, которые хавают время выполнения.

[OtherSide]

Не виртуалка. Ryzen 7700x

[Next]

Не виртуалка. Ryzen 7700x

Тогда мистика какая-то. Попробуйте ради интереса создать новый пустой проект, развернуть его в докере, после чего откомпилить у release и запустить. Какие будут задержки?

[OtherSide]

Не виртуалка. Ryzen 7700x

Тогда мистика какая-то. Попробуйте ради интереса создать новый пустой проект, развернуть его в докере, после чего откомпилить у release и запустить. Какие будут задержки?

Я же говорю это и был пустой проект - туториал

[Next]

Не виртуалка. Ryzen 7700x

Тогда мистика какая-то. Попробуйте ради интереса создать новый пустой проект, развернуть его в докере, после чего откомпилить у release и запустить. Какие будут задержки?

Я же говорю это и был пустой проект - туториал

Так а он в студии в дебаге был запущен, или прямо в докере, с вызовом сервисов напрямую из браузера?

[OtherSide]

в дебаггере в цикле 100 запросов делал. По скорости как get запросы получилось

[Next]

в дебаггере в цикле 100 запросов делал. По скорости как get запросы получилось

Подключенный дебаггер сжирает колоссальное количество ресурсов. Для чистоты эксперимента нужно откомпилировать проект в release и задеплоить в докер. А уже потом смотреть задержки.