Live data from Hacker News

gRPC: Internet-scale RPC framework is now 1.0

cloudplatform.googleblog.com

21–30 of 111 posts

Re: gRPC: Internet-scale RPC framework is now 1.0

#21
post #4

Anyone here who tried out gRPC or is using it in production, and can share some experiences?

We use it heavily on multiple projects across languages, and for the most part it works very well. We've had some pain about sharing proto definitions across languages and keeping them in sync. It's probably a much smaller problem when you've got a company-wide monorepo like Google, but you'll definitely have to be vigilant about your build processes to make sure you have the latest definitions shared.

Some of the language bindings (Ruby) started off feeling experimental quality when we began the project, but overall it's been a huge win for us versus HTTP+JSON. I'm sure a non-zero portion of the benefit has been using protobufs at all, but gRPC gives us a great way to generate clients for every language we use without worrying.

Re: gRPC: Internet-scale RPC framework is now 1.0

#23
post #7
post #4

Anyone here who tried out gRPC or is using it in production, and can share some experiences?

caveat: I work in gRPC team. read target blogpost link to get a sense of experience of some of the companies. https://cloudplatform.googleblog.com/2016/08/gRPC-a-true-Int...

That's the original link! You tricked me :)

Re: gRPC: Internet-scale RPC framework is now 1.0

#26
post #4

Anyone here who tried out gRPC or is using it in production, and can share some experiences?

We're using grpc-java in production for some of our based backend system, slowly replacing our old netty/jackson based system using JSON over HTTP/1.1.

The performance is good, and it's nice to have proto files with messages and services, which acts both as documentation and a way to generate client and server code. Protobuf is much faster, produces less garbage and is easier to work with than JSON/jackson. The generated stubs are very good and it's easy to switch between blocking and asynchronous requests, which still only require a single tcp/ip connection.

We've had two performance problems with it:

1. Connections can die in a somewhat unexpected way. This turned out to be caused by HTTP/2.0 which only allows 1 billion streams over a single connection. Maybe not a common issue, but it hurt us because we had a few processes reaching this limit at the same time, breaking our redundancy. It's easy work around it, and I believe the grpc-java team has plan for a fix that would make this invisible to a single channel.

2. Mixing small/low-latency requests with large/slow requests caused very unstable latency for the low-latency requests. Our current work-around is to start two grpc servers (still within the same java process and sharing the same resources). The difference is huge with 99p going from 22ms to 2.4ms just by using two different ports. Our old code with JSON over HTTP/1.1 implemented using jackson and netty didn't suffer this unstability in latency, so I suspect grpc is doing too much work inside a netty worker or something. I haven't yet tested with grpc-java 1.0, which I see has gotten a few optimization.

Still, these have been minor issues, and we're happy so far. The grpc-java team is doing a good job taking care of things, both with code and communication.

Re: gRPC: Internet-scale RPC framework is now 1.0

#27
post #7
post #4

Anyone here who tried out gRPC or is using it in production, and can share some experiences?

caveat: I work in gRPC team. read target blogpost link to get a sense of experience of some of the companies. https://cloudplatform.googleblog.com/2016/08/gRPC-a-true-Int...

So gRPC evolved out of Stubby. An excellent show of force would be to announce that Stubby has been internally replaced by gRPC, so that the "gRPC is internet scale" assertion can be more than just a gimmick. Knowing nothing of the first one and very little of the second I imagine it would be some important task, so I have to ask: do you plan to internally run with the stuff you open-sourced ? What is missing ?

Re: gRPC: Internet-scale RPC framework is now 1.0

#29
post #25

Something I've wondered for awhile: why would I want to design with gRPC rather than well-defined HTTP/JSON endpoints? Is it just a perf thing?

Performance and versioning are two large benefits.

Performance benefit comes from the fact that schema is defined on each side (generally server / server) so you only send the information bytes. With a good RPC system you can also access specific fields of your structure without unpacking (or very fast unpacking, depends on what RPC system you're using).

gRPC uses Google's protocol buffers. https://developers.google.com/protocol-buffers

Comparable systems use other IDLs, e.g Facebook uses Apache Thrift.

Versioning is easier because your fields are defined explicitly, so you can ignore clients sending an old field to no ill effect (again, you can access individual fields without unpacking). Whereas with json you need to deserialize first. Also if your schema changes when using json without protobufs, you may experience either the client or the server making the wrong assumptions about input data. Whereas there is no ambiguity with protobufs; future changes to proto messages add fields and old fields can just be marked deprecated.

RPC is preferable to JSON for server-to-server communication, but client-server still often uses json just because it's often easier for your client app to interpret json. Systems like gRPC allow servers to emit json as well: https://developers.google.com/protocol-buffers/docs/proto3#j...

I've heard of performance-oriented web apps using protobufs on both client and server.

Post reply on HN