#grpc

Hello.

Is gRPC meant for connecting back-end services, in a controlled environment.

Or it's suitable for public-facing Web APIs too?

bomb: we intend for it to be an attractive solution for both of those use cases as well as others. :-)

nathanielmanist1: That's excellent. It looks like Thrift or ZeroMQ, but webscale.

Does the browser need to support HTTP 2 to talk to gRPC?

i have some questions, can someone help ?

don't ask to ask, just ask :)

can i use the only one channel created for stub to serve multiple request ?

because as far as i know, you can create multiple connection in a channel.

and channel will take care of the part when to create new connection

Udit: Yes, Channel handles the connections, and it can handle multiple RPCs over the same connection simultaneously.

It automatically connects and reconnects as necessary.

so i can cache the created channel and use it for the lifetime of client ?

does it sound wrong ?

Yep, that sounds good.

another thing i noticed is, simple greeting service when i implemented in grpc vs thrift.

10000 RPC from one client time take by grpc/thrift is like this 3200/290 ms.

i did not get how thrift is so faster ?

Udit: It's probably a problem with the benchmark. I'd have to know how many requests you did concurrently and how many Thrift connections you made to give more details.

Ejona: GRPC-> i am making 10k rpc calls in sequence. no parallel request. for (int i = 0; i < 10000; i++) { blockingStub.sayHello("Hi there !!"); }

Okay, so you made a latency test.

yeah.

That puts gRPC latency at 320µs and thrift at 29µs. 29µs is an incredible number. I assume you are accessing localhost?

yes

thats correct. i am doing all at localhost

I think Thrift is benefitting from being blocking. That is effectively the speed of netperf tcp_rr.

But in Java, threads are very expensive, so gRPC-Java is async by nature.

Also, in that setup thrift can't multiplex multiple RPCs on the same TCP connection, I believe.

I can't quite compare to our own benchmarks, because tcp_rr is ~100µs in our benchmark environment.

Udit: Does your envisioned usage actually coorespond to a closed-loop benchmark like that? Or would you expect "random" RPCs from multiple threads?