Unfortunately, Jack question was about the golang version of grpc, so these don't apply here :-)
We'll get someone from the grpc-go team to reply here. On Sat, Aug 27, 2016, 17:17 Paul Grosu <[email protected]> wrote: > > Hi Jack, > > So I believe a lot of this stuff might not yet be documented - and I think > Mark Roth is working on it - so you would be relying on my memory, which I > hope you don't mind :) This will be a fun team effort. So you can start a > TCP server via the grpc_tcp_server_start method as defined here: > > > https://github.com/grpc/grpc/blob/master/src/core/lib/iomgr/tcp_server_posix.c#L682-L722 > > Keep in mind that you can create a TCP endpoint via the grpc_tcp_create > method as defined here: > > > https://github.com/grpc/grpc/blob/master/src/core/lib/iomgr/tcp_posix.c#L467-L493 > > One thing to note that the endpoint is defined via the vtable, which is a > grpc_endpoint_vtable struct type, where you put references of your > transport functions for reading, writing, etc. as such: > > static const grpc_endpoint_vtable vtable = {tcp_read, > tcp_write, > tcp_get_workqueue, > tcp_add_to_pollset, > tcp_add_to_pollset_set, > tcp_shutdown, > tcp_destroy, > tcp_get_peer}; > > The above is defined on the following lines: > > > https://github.com/grpc/grpc/blob/master/src/core/lib/iomgr/tcp_posix.c#L458-L465 > > If you are unfamiliar with the endpoint definition it is in the following > file: > > > https://github.com/grpc/grpc/blob/master/src/core/lib/iomgr/endpoint.h#L49-L62 > > And looks like this: > > /* An endpoint caps a streaming channel between two communicating > processes. > Examples may be: a tcp socket, <stdin+stdout>, or some shared memory. */ > > typedef struct grpc_endpoint grpc_endpoint; > typedef struct grpc_endpoint_vtable grpc_endpoint_vtable; > > struct grpc_endpoint_vtable { > void (*read)(grpc_exec_ctx *exec_ctx, grpc_endpoint *ep, > gpr_slice_buffer *slices, grpc_closure *cb); > void (*write)(grpc_exec_ctx *exec_ctx, grpc_endpoint *ep, > gpr_slice_buffer *slices, grpc_closure *cb); > grpc_workqueue *(*get_workqueue)(grpc_endpoint *ep); > void (*add_to_pollset)(grpc_exec_ctx *exec_ctx, grpc_endpoint *ep, > grpc_pollset *pollset); > void (*add_to_pollset_set)(grpc_exec_ctx *exec_ctx, grpc_endpoint *ep, > grpc_pollset_set *pollset); > void (*shutdown)(grpc_exec_ctx *exec_ctx, grpc_endpoint *ep); > void (*destroy)(grpc_exec_ctx *exec_ctx, grpc_endpoint *ep); > char *(*get_peer)(grpc_endpoint *ep); > }; > > So basically you can write your own transport functions if you prefer. > Again all of this was based on my reading of the code for some time, but if > anyone thinks I misinterpreted something please correct me. > > Hope it helps, > Paul > > > > On Friday, August 26, 2016 at 12:36:39 PM UTC-4, [email protected] wrote: >> >> 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/f14ec1d8-31e7-4f71-ac8a-907065e3bad4%40googlegroups.com > <https://groups.google.com/d/msgid/grpc-io/f14ec1d8-31e7-4f71-ac8a-907065e3bad4%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- 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/CAOWnRi_Si-U2hK8ZFcamaMiMxQwRijJpdRKTfei1Dm%3DkyBgkHw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
