Hi community, We've run some informal benchmark to compare gRPC-go's performance with other alternatives. It's apparent that gRPC could improve in this area. One option that we'd like to experiment is to see how much performance gain we would get by using TCP instead of HTTP 2.0. I understand that HTTP2.0 has been one of the core values of the gRPC projects, but it would be interesting to understand its performance implication and explore the TCP option that might fit well in many scenarios. In order to do so, I'd like to get some advice on how to replace the transport layer. Is it sufficient to replace the implementation in the google.golang.org/grpc/transport/ package? Our initial experiment indicates that some code in the call/invocation layer are coupled with HTTP 2.0 transport, e.g., the context remembers some HTTP 2.0 related status. Your advice on how to do a clean switch to TCP would be appreciated.
Below is our benchmark data - please note it's an informal benchmark, so just for people's casual reference. *Test method*: use three client machines, each making 10 connections to one server and then keep making a "hello" request in a loop (no new goroutines created); both the request and response contains a 1K sized message. *gRPC-go* Max TPS: 180K, Ave. latency: 0.82ms, server CPU: 67% *Go native RPC* Max TPS: 300K, Ave. latency: 0.26ms, server CPU: 37% *Apache Thrift with Go* Max TPS: 200K, Ave. latency: 0.29ms, server CPU: 21% Jack -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/842a7e72-7e24-4dc2-b009-3ce2c698ea47%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
