Здравствуйте, takTak, Вы писали:

T>с целью интеграции сторонней старой дотнетовской dll решил написать сервер, который бы заворачивал вызов этой dll, так что из нового .net core приложения можно было бы по http или http/2 вызывать эту старую функциональность, хотелось сравнить старый web api с новым grpc, ну я выбрал gRPC-Web, ну так вот получилось, что вызов по gRPC-Web раза в два- три получается медленнее, чем asp.net web api; gRPC-server хостился во время измерений в обычной консоле, а web api в iis express, и то и другое компилировалось под .net 4.6.2, как такое вообще может быть, что gRPC-Web получился медленнее??

T>ещё хочу добавить: для сериализации использовал protobuf-net.Grpc: неужели там такие проблемы?

Может лучше таки просто gRPC, а не gRPC-Web?

Здравствуйте, takTak, Вы писали:

T>с целью интеграции сторонней старой дотнетовской dll решил написать сервер, который бы заворачивал вызов этой dll, так что из нового .net core приложения можно было бы по http или http/2 вызывать эту старую функциональность, хотелось сравнить старый web api с новым grpc, ну я выбрал gRPC-Web, ну так вот получилось, что вызов по gRPC-Web раза в два- три получается медленнее, чем asp.net web api; gRPC-server хостился во время измерений в обычной консоле, а web api в iis express, и то и другое компилировалось под .net 4.6.2, как такое вообще может быть, что gRPC-Web получился медленнее??

T>ещё хочу добавить: для сериализации использовал protobuf-net.Grpc: неужели там такие проблемы?

gRPC-Web для поодержки браузеров
https://docs.microsoft.com/ru-ru/aspnet/core/grpc/browser?view=aspnetcore-3.1
Сервер может работать и по gRPC-Web и по gRPC

public void ConfigureServices(IServiceCollection services)
{
services.AddGrpc();
}

public void Configure(IApplicationBuilder app)
{
app.UseRouting();

app.UseGrpcWeb(); // Must be added between UseRouting and UseEndpoints

app.UseEndpoints(endpoints =>
{
endpoints.MapGrpcService<GreeterService>().EnableGrpcWeb();
});
}

Посмотри https://github.com/Cysharp/MagicOnion
Там есть

MagicOnion allows primitive, multiple request value. Complex type is serialized by LZ4 Compressed MsgPack by MessagePack for C# so type should follow MessagePack for C# rules.

T>>с целью интеграции сторонней старой дотнетовской dll решил написать сервер, который бы заворачивал вызов этой dll, так что из нового .net core приложения можно было бы по http или http/2 вызывать эту старую функциональность, хотелось сравнить старый web api с новым grpc, ну я выбрал gRPC-Web, ну так вот получилось, что вызов по gRPC-Web раза в два- три получается медленнее, чем asp.net web api; gRPC-server хостился во время измерений в обычной консоле, а web api в iis express, и то и другое компилировалось под .net 4.6.2, как такое вообще может быть, что gRPC-Web получился медленнее??

T>>ещё хочу добавить: для сериализации использовал protobuf-net.Grpc: неужели там такие проблемы?

VC>ничего не понятно. заверни поднятие сервера в [GlobalSetup]-метод, а вызов сервера в [Benchmark]-метод

VC>И выложи на github/gitlab

VC>сможеш?

да, ты прав,
залил только что на гитхаб

сейчас получается вот так :


т.е. быстрее чем Web Api, но на 40 % дольше, чем локально, почему так долго?

с целью интеграции сторонней старой дотнетовской dll решил написать сервер, который бы заворачивал вызов этой dll, так что из нового .net core приложения можно было бы по http или http/2 вызывать эту старую функциональность, хотелось сравнить старый web api с новым grpc, ну я выбрал gRPC-Web, ну так вот получилось, что вызов по gRPC-Web раза в два- три получается медленнее, чем asp.net web api; gRPC-server хостился во время измерений в обычной консоле, а web api в iis express, и то и другое компилировалось под .net 4.6.2, как такое вообще может быть, что gRPC-Web получился медленнее??

ещё хочу добавить: для сериализации использовал protobuf-net.Grpc: неужели там такие проблемы?

Здравствуйте, takTak, Вы писали:

T>с целью интеграции сторонней старой дотнетовской dll решил написать сервер, который бы заворачивал вызов этой dll, так что из нового .net core приложения можно было бы по http или http/2 вызывать эту старую функциональность, хотелось сравнить старый web api с новым grpc, ну я выбрал gRPC-Web, ну так вот получилось, что вызов по gRPC-Web раза в два- три получается медленнее, чем asp.net web api; gRPC-server хостился во время измерений в обычной консоле, а web api в iis express, и то и другое компилировалось под .net 4.6.2, как такое вообще может быть, что gRPC-Web получился медленнее??

T>ещё хочу добавить: для сериализации использовал protobuf-net.Grpc: неужели там такие проблемы?

ничего не понятно. заверни поднятие сервера в [GlobalSetup]-метод, а вызов сервера в [Benchmark]-метод

И выложи на github/gitlab

сможеш?

S>Посмотри https://github.com/Cysharp/MagicOnion
S>Там есть
S>

S>MagicOnion allows primitive, multiple request value. Complex type is serialized by LZ4 Compressed MsgPack by MessagePack for C# so type should follow MessagePack for C# rules.

ну эта штука похожа в плане сериализации на protobuf-net.Grpc, просто по числу подписавшихся на проект выглядит поскромее, ты это использовал? сравнивал со скоростью через web api?

Здравствуйте, takTak, Вы писали:

S>>Посмотри https://github.com/Cysharp/MagicOnion
S>>Там есть
S>>

S>>MagicOnion allows primitive, multiple request value. Complex type is serialized by LZ4 Compressed MsgPack by MessagePack for C# so type should follow MessagePack for C# rules.

T>ну эта штука похожа в плане сериализации на protobuf-net.Grpc, просто по числу подписавшихся на проект выглядит поскромее, ты это использовал? сравнивал со скоростью через web api?
Нет не пробовал. У меня коллега на него глаз положил.
Кстати
https://docs.microsoft.com/ru-ru/aspnet/core/signalr/messagepackhubprotocol?view=aspnetcore-3.1

T>>ещё хочу добавить: для сериализации использовал protobuf-net.Grpc: неужели там такие проблемы?

V_G>Может лучше таки просто gRPC, а не gRPC-Web?

да, сорри, я перепутал: т.е. я не gRPC-Web, а gRPC использовал, всё равно по сравнению с локальным вызовом как-то долго получается...

Здравствуйте, takTak, Вы писали:

T>да, сорри, я перепутал: т.е. я не gRPC-Web, а gRPC использовал, всё равно по сравнению с локальным вызовом как-то долго получается...

А ты хотел чтобы вызов через несколько процессов и через стек TCP/IP был сопоставим по скорости с локальным? Серьезно?

T>>да, сорри, я перепутал: т.е. я не gRPC-Web, а gRPC использовал, всё равно по сравнению с локальным вызовом как-то долго получается...

НС>А ты хотел чтобы вызов через несколько процессов и через стек TCP/IP был сопоставим по скорости с локальным? Серьезно?

что значит "несколько процессов" ? речь идёт о коммуникации без сетевого трафика между двумя процессами на одной и той же машине, прочём с использованием бинарной сериализации, у меня на боевой машине получается разница в 15 -40 раз, откуда такое берётся ?! ну раза в 2-3 ещё куда ни шло...

Здравствуйте, takTak, Вы писали:

T>>>да, сорри, я перепутал: т.е. я не gRPC-Web, а gRPC использовал, всё равно по сравнению с локальным вызовом как-то долго получается...

НС>>А ты хотел чтобы вызов через несколько процессов и через стек TCP/IP был сопоставим по скорости с локальным? Серьезно?

T>что значит "несколько процессов" ? речь идёт о коммуникации без сетевого трафика между двумя процессами на одной и той же машине, прочём с использованием бинарной сериализации, у меня на боевой машине получается разница в 15 -40 раз, откуда такое берётся ?! ну раза в 2-3 ещё куда ни шло...

Ну я так понял из кода, что SomeLegacyService вызывается из текущего процесса

public class SomeLegacyService: IService
    {
        public Result CalculateSomething(RequestDto request)
        {
            try
            {
                //Thread.Sleep(TimeSpan.FromMilliseconds(10));

                return FakeDataProvider.Instance.GetResult();
                
             }
            catch (Exception ex)
            {
                throw;
            }
        }
    }

А вэб и gRPC подключаются к отдельным процессам.
Хоть и говорят, что gRPC прирост за счет постоянного соединения, но у меня максимум в 2 раза получилось. Хотя на TCP/IP на одной машине разница раз в 7-10
https://ru.stackoverflow.com/questions/630653/tcp-ip-%d1%81%d0%ba%d0%be%d1%80%d0%be%d1%81%d1%82%d1%8c-%d0%be%d0%b1%d0%bc%d0%b5%d0%bd%d0%b0/634019#634019

Здравствуйте, takTak, Вы писали:

T>>>ещё хочу добавить: для сериализации использовал protobuf-net.Grpc: неужели там такие проблемы?

V_G>>Может лучше таки просто gRPC, а не gRPC-Web?

T>да, сорри, я перепутал: т.е. я не gRPC-Web, а gRPC использовал, всё равно по сравнению с локальным вызовом как-то долго получается...

где ты взял это выражение "локальный вызов" Под локальным вызовом подразумевается вызов сервиса в другом процессе на том же сервере/ПК.

ты вместо "локальный вызов" пиши "in-process вызов", иначе тебя никто не поймёт

S>Хоть и говорят, что gRPC прирост за счет постоянного соединения, но у меня максимум в 2 раза получилось. Хотя на TCP/IP на одной машине разница раз в 7-10
S>https://ru.stackoverflow.com/questions/630653/tcp-ip-%d1%81%d0%ba%d0%be%d1%80%d0%be%d1%81%d1%82%d1%8c-%d0%be%d0%b1%d0%bc%d0%b5%d0%bd%d0%b0/634019#634019

ну в примере же не стриминг (тогда бы и было постоянное соединение), и если заглянуть под капот, то клиентская сторона отправляет всё не по Tcp/Udp, а через обычный HttpClient, так что экономия -лишь на размере того, что через Http отправляется,

но всё равно я большего ожидал

через обычноe Web Api + http Client (json) получается разница с in-process где-то около 30 -40 раз, что тоже как-то imho сильно много

под конец gRpc вообще загнулся: то ли с firewall/microsoft defender и портами были какие-то проблемы, то ли админы опять с чем-то играются, так что localhost толком не разрешался, то ли gRpc с обычным .Net фреймворком не дружит, короче перестало работать, а причина- хз... короче, сыровато пока поделие

Здравствуйте, takTak, Вы писали:

T>что значит "несколько процессов" ?

Значит несколько процессов.

T> речь идёт о коммуникации без сетевого трафика между двумя процессами на одной и той же машине

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

T>, прочём с использованием бинарной сериализации, у меня на боевой машине получается разница в 15 -40 раз,

Это офигенно маленькая разница.

T> откуда такое берётся ?! ну раза в 2-3 ещё куда ни шло...

Ты реально не понимаешь в чем разница между одной инструкцией процессора и работой полноценного сетевого стека?

Здравствуйте, takTak, Вы писали:


S>>Хоть и говорят, что gRPC прирост за счет постоянного соединения, но у меня максимум в 2 раза получилось. Хотя на TCP/IP на одной машине разница раз в 7-10
S>>https://ru.stackoverflow.com/questions/630653/tcp-ip-%d1%81%d0%ba%d0%be%d1%80%d0%be%d1%81%d1%82%d1%8c-%d0%be%d0%b1%d0%bc%d0%b5%d0%bd%d0%b0/634019#634019

T>ну в примере же не стриминг (тогда бы и было постоянное соединение), и если заглянуть под капот, то клиентская сторона отправляет всё не по Tcp/Udp, а через обычный HttpClient, так что экономия -лишь на размере того, что через Http отправляется,

В примере как раз стриминг

 static byte[] SendMessage(byte[] ms, IPEndPoint IpEndpoint)
        {

            using (var client = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp))
            {
                client.Connect(IpEndpoint);
                //      client.NoDelay = true;

                using (var ns = new NetworkStream(client))
                {

                    ns.Write(BitConverter.GetBytes(ms.Length), 0, 4);
                    ns.Write(ms, 0, ms.Length);

                    using (var br = new BinaryReader(ns))
                    {
                        var streamSize = br.ReadInt32();

                        var res = br.ReadBytes(streamSize);

                        return res;
                    }

                }

Просто в одном случае мы закрываем соединение на клиентской стороне, а в другом случае используем открытое соединение.

static byte[] SendMessage2(byte[] ms, NetworkStream ns)
        {

            ns.Write(BitConverter.GetBytes(ms.Length), 0, 4);
            ns.Write(ms, 0, ms.Length);

Кстати можно сравнить и с Tcp/Ip
И с SignalR
https://ru.wikipedia.org/wiki/WebSocket#:~:text=WebSocket%20%E2%80%94%20%D0%BF%D1%80%D0%BE%D1%82%D0%BE%D0%BA%D0%BE%D0%BB%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%BF%D0%BE%D0%B2%D0%B5%D1%80%D1%85%20TCP,%D1%81%D0%B5%D1%80%D0%B2%D0%B5%D1%80%D0%BE%D0%BC%20%D0%B2%20%D1%80%D0%B5%D0%B6%D0%B8%D0%BC%D0%B5%20%D1%80%D0%B5%D0%B0%D0%BB%D1%8C%D0%BD%D0%BE%D0%B3%D0%BE%20%D0%B2%D1%80%D0%B5%D0%BC%D0%B5%D0%BD%D0%B8.

T>>что значит "несколько процессов" ?

НС>Значит несколько процессов.

два- это не несколько, два- это пара

T>> речь идёт о коммуникации без сетевого трафика между двумя процессами на одной и той же машине

НС>Межпроцессное взаимодействие тоже не бесплатно. А уж если речь про полноценный сетевой стек, то и подавно.

T>>, прочём с использованием бинарной сериализации, у меня на боевой машине получается разница в 15 -40 раз,

НС>Это офигенно маленькая разница.

это зависит от того, насколько быстро завершается in-process операция: если через час, то затраты на (де)сериализацию и отправку/получение может никто и не заметит

T>> откуда такое берётся ?! ну раза в 2-3 ещё куда ни шло...

НС>Ты реально не понимаешь в чем разница между одной инструкцией процессора и работой полноценного сетевого стека?

какая ещё одна инструкция? в одном случае идёт калькуляция результата, в другом же — просто завёртка и развертка полученного результата, это разные вещи

Здравствуйте, takTak, Вы писали:

НС>>Значит несколько процессов.
T>два- это не несколько, два- это пара

Это все меняет.

НС>>Ты реально не понимаешь в чем разница между одной инструкцией процессора и работой полноценного сетевого стека?
T>какая ещё одна инструкция?

А сколько, по твоему, надо инструкций для in-process call?

T> в одном случае идёт калькуляция результата, в другом же — просто завёртка и развертка полученного результата, это разные вещи

Не распарсил.

НС>>>Значит несколько процессов.
T>>два- это не несколько, два- это пара

НС>Это все меняет.

это разные слова и сложность, отличающаяся во столько раз, во сколько раз "несколько" больше "двух": как минимум, это разы

НС>>>Ты реально не понимаешь в чем разница между одной инструкцией процессора и работой полноценного сетевого стека?
T>>какая ещё одна инструкция?

НС>А сколько, по твоему, надо инструкций для in-process call?

я не говорил про какой-то там один call, я говорил о результате вычислительной операции, которая может состоять из миллиардов инструкций

T>> в одном случае идёт калькуляция результата, в другом же — просто завёртка и развертка полученного результата, это разные вещи

НС>Не распарсил.

не благодари

Здравствуйте, takTak, Вы писали:



T>это зависит от того, насколько быстро завершается in-process операция: если через час, то затраты на (де)сериализацию и отправку/получение может никто и не заметит

В межпроцессном взаимодействии кучу времени съедает передача данных между процессами, которая может быть в сотни раз больше чем затраты на сериализацию десериализацию и сжатие данных.
Это в Com проходили с внутренним сервером автоматизации (dll) и внешним (exe)

T>>ну в примере же не стриминг (тогда бы и было постоянное соединение), и если заглянуть под капот, то клиентская сторона отправляет всё не по Tcp/Udp, а через обычный HttpClient, так что экономия -лишь на размере того, что через Http отправляется,

S> В примере как раз стриминг

тоже про свой пример говорил

просто проблемы начинаются тогда, когда надо прикручивать client factory, retry policy, timeout & error handling, server sessions, instancing, and concurrency: там где нестандартно, а это почти везде, где не http, поджидают самые разные пакости

Здравствуйте, takTak, Вы писали:


T>>>ну в примере же не стриминг (тогда бы и было постоянное соединение), и если заглянуть под капот, то клиентская сторона отправляет всё не по Tcp/Udp, а через обычный HttpClient, так что экономия -лишь на размере того, что через Http отправляется,

S>> В примере как раз стриминг

T>тоже про свой пример говорил

T>просто проблемы начинаются тогда, когда надо прикручивать client factory, retry policy, timeout & error handling, server sessions, instancing, and concurrency: там где нестандартно, а это почти везде, где не http, поджидают самые разные пакости

Ну внутри того же HTTP/2 постоянное соединение плюс

Протокол HTTP/2 является бинарным[13][14]. По сравнению с предыдущим стандартом изменены способы разбиения данных на фрагменты и транспортирования их между сервером и клиентом.

В HTTP/2 сервер имеет право послать то содержимое, которое ещё не было запрошено клиентом. Это позволит серверу сразу выслать дополнительные файлы, которые потребуются браузеру для отображения страниц, без необходимости анализа браузером основной страницы и запрашивания необходимых дополнений.

Также часть улучшений получена (в первом черновике HTTP/2, который представлял собой копию спецификации SPDY) за счёт мультиплексирования запросов и ответов (для преодоления проблемы «head-of-line blocking» протоколов HTTP/1.x), а также за счёт сжатия передаваемых заголовков и введения явной приоритизации запросов.

Тот же Web Api тоже можно гонять через HTTP/2

S> Ну внутри того же HTTP/2 постоянное соединение плюс
S>

S>Протокол HTTP/2 является бинарным[13][14]. По сравнению с предыдущим стандартом изменены способы разбиения данных на фрагменты и транспортирования их между сервером и клиентом.

S>В HTTP/2 сервер имеет право послать то содержимое, которое ещё не было запрошено клиентом. Это позволит серверу сразу выслать дополнительные файлы, которые потребуются браузеру для отображения страниц, без необходимости анализа браузером основной страницы и запрашивания необходимых дополнений.

S>Также часть улучшений получена (в первом черновике HTTP/2, который представлял собой копию спецификации SPDY) за счёт мультиплексирования запросов и ответов (для преодоления проблемы «head-of-line blocking» протоколов HTTP/1.x), а также за счёт сжатия передаваемых заголовков и введения явной приоритизации запросов.

S> Тот же Web Api тоже можно гонять через HTTP/2

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

с тем же хостингом — проблемы: если я хочу gRpc в обычном .NET захостить , то надо ведь своими ручками windows service писать, или?

Здравствуйте, takTak, Вы писали:

НС>>>>Значит несколько процессов.
T>>>два- это не несколько, два- это пара
НС>>Это все меняет.
T>это разные слова и сложность, отличающаяся во столько раз, во сколько раз "несколько" больше "двух": как минимум, это разы

Не распарсил.

НС>>А сколько, по твоему, надо инструкций для in-process call?
T>я не говорил про какой-то там один call,

Ты вообще ничего конкретно не говорил.

T> я говорил о результате вычислительной операции, которая может состоять из миллиардов инструкций

А может и не состоять, да? Замерь потери на вызов, тогда можно будет что то обсуждать. Иначе разговор ни о чем.

T>>> в одном случае идёт калькуляция результата, в другом же — просто завёртка и развертка полученного результата, это разные вещи
НС>>Не распарсил.
T>не благодари

Ты там бухаешь что ли?

Здравствуйте, takTak, Вы писали:

S>> Тот же Web Api тоже можно гонять через HTTP/2

T>насколько я понял, это не для всего подходит: для стриминга хорошо подходит, наверное, если же надо время от времени просто выдёргивать какие-то данные, то могут возникать проблемы, во всяком случае, год назад народ ещё жаловался

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

T>с тем же хостингом — проблемы: если я хочу gRpc в обычном .NET захостить , то надо ведь своими ручками windows service писать, или?
Ну по https://docs.microsoft.com/ru-ru/aspnet/core/tutorials/grpc/grpc-start?view=aspnetcore-3.1&amp;tabs=visual-studio