vsaroopchand / ServiceFabric-Performance-Test

How do each OOtB ICommunicationListeners stack up to each-other? This project is an attempt to visualize the performance metrics of each OOtB and custom communication stacks.
4 stars 0 forks source link

Remoting V2 stack and gRPC #1

Open MedAnd opened 6 years ago

MedAnd commented 6 years ago

Would be great to see Remoting V2 stack and gRPC also compared:

  1. https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-reliable-services-communication-remoting
  2. https://github.com/mholo65/service-fabric-grpc-playground
vsaroopchand commented 6 years ago

I added gRPC communication listener, here are some observations: https://myspp.blob.core.windows.net/results/5NodeCloud_Azure_VM_D2_v2_Standard_ZoomOut.jpg https://myspp.blob.core.windows.net/results/5NodeCloud_Azure_VM_D2_v2_Standard.jpg https://myspp.blob.core.windows.net/results/5NodeDev_Azure_VM_D8S_V3_Standard.jpg

I am curious as to why DotNetty preforms much better in the cloud cluster. Must be something with the localhost addressing. I will investigate this further.

I'll incorporate V2 remoting next.

MedAnd commented 6 years ago

Hi @vsaroopchand, if I'm reading the new results correctly it seems even remoting v1 performs better than gRPC... very unexpected given the highly optimized Protocol Buffers serialization used by gRPC vs slow serialization used in remoting v1.

Some questions about the test, noticed the comment: convert protobuffer message to Datacontract and send it back to web proxy using http.. wondering if this means you are using gRPC from api gateway --> service1 --> service2 --> service3 then using http from --> service3 --> api gateway? Also is the code in Common/Grpc/ using async send with fire and forget or async request/response?

PS. When I get some time hope to dig-up my own old gRPC vs remoting v1 test... I did a simple ping pong between a Stateless Service and a command line test harness, on a single node local cluster... this should remove any network hops, partition resolution etc from the equation...

MedAnd commented 6 years ago

Believe this will become the default transport: KestrelCommunicationListener

vsaroopchand commented 6 years ago

Currently, the solution uses a custom serialize relying on JSON.NET which was bench-marked to be much faster than data contract serialization. Also, messages from SVC3 back to WebAPI is using http so we have to disregard the last leg. I will revisit the gRPC implementation as well, it is using request/response model. I didn’t expect it would impact the overall duration since the message is stamped upon arrival. But, I will eliminate that factor to be consistent with the others.

senthilkumar79 commented 6 years ago

Hi @vsaroopchand, i am not able to see the https://myspp.blob.core.windows.net/results/5NodeCloud_Azure_VM_D2_v2_Standard_ZoomOut.jpg https://myspp.blob.core.windows.net/results/5NodeCloud_Azure_VM_D2_v2_Standard.jpg https://myspp.blob.core.windows.net/results/5NodeDev_Azure_VM_D8S_V3_Standard.jpg

interested to see the comparison between remoting v1 or remoting v2 VS gRPC performance in service fabric as MedAnd written in his comments .. is remoting v1 or remoting v2 is better than gRPC

tbertenshaw commented 6 years ago

@vsaroopchand the images don't appear to be viewable any more?

olegkv commented 4 years ago

I noticed that Remoting call also stores data in Reliable Collection, while other calls don't. What's the point of including data call which writes data to disk into a protocol comparison? Not sure I understand it.