с целью интеграции сторонней старой дотнетовской 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

сможеш?

Здравствуйте, 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.

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>>с целью интеграции сторонней старой дотнетовской 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 % дольше, чем локально, почему так долго?

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, поджидают самые разные пакости