4 ms·

Since you brought it up, what are your (or anyone in-the-know's) opinions on transferring large (~GB) files via gRPC? I recently implemented my first gRPC serv

Since you brought it up, what are your (or anyone in-the-know's) opinions on transferring large (~GB) files via gRPC? I recently implemented my first gRPC service and while it went nicely, I ended up writing a somewhat gross HTTP service along side the gRPC service to push and pull bytes to. After some short research (not testing myself!), it sounds like gRPC has significant overhead for large files due to having to chunk each file up, and the byte chunks end up not being efficient on CPU time/etc. Since my download service required no security/etc that gRPC might excel at, I just used gRPC for setting up the download/upoad, querying data, etc. It would have been much simpler to fully use gRPC for the upload and download, but it sounded costly. With no specific question, what are your thoughts on gRPC streaming "large" data? example perf tests: https://ops.tips/blog/sending-files-via-grpc/ https://ops.tips/blog/sending-files-via-grpc/

Matthias247 8y ago
In an ideal implementation it should be pretty much as fast as plain HTTP/2, since the overhead is only a bit of protobuf framing between chunks. Which depending on the chunk size is negligible. However what I think comes into play in the benchmark is the behavior of the real library, and most likely the garbage collector. There might be paths in the code where the each chunk is freshly allocated and later on dropped. This gets more costly if chunks get bigger, which might explain the degradation in the measurements. In this example the client's chunk size is allocated once and everything else is a cheap slice, which should be good. However for the server I'm not sure, I guess it might allocate the buffer for each chunk just in order to drop it later on. Then you could investigate if you can give protobuf a prepopulated data structure with a reserved maximum size (e.g. from a pool) that it should use for deserialization, which might speed things up. Another thing which obviously comes into play is the performance of HTTP/2 implementations, which may vary a lot. I think even for Go, the HTTP/2 implementation in the net package and the one in grpc where different (not sure if they unified them now, there was an attempt on the way). So the question would need to be investigated separately for each of those.
- notheguyouthink 8y ago
  Appreciate your insight!

Matthias247 8y ago

In an ideal implementation it should be pretty much as fast as plain HTTP/2, since the overhead is only a bit of protobuf framing between chunks. Which depending on the chunk size is negligible. However what I think comes into play in the benchmark is the behavior of the real library, and most likely the garbage collector. There might be paths in the code where the each chunk is freshly allocated and later on dropped. This gets more costly if chunks get bigger, which might explain the degradation in the measurements. In this example the client's chunk size is allocated once and everything else is a cheap slice, which should be good. However for the server I'm not sure, I guess it might allocate the buffer for each chunk just in order to drop it later on. Then you could investigate if you can give protobuf a prepopulated data structure with a reserved maximum size (e.g. from a pool) that it should use for deserialization, which might speed things up. Another thing which obviously comes into play is the performance of HTTP/2 implementations, which may vary a lot. I think even for Go, the HTTP/2 implementation in the net package and the one in grpc where different (not sure if they unified them now, there was an attempt on the way). So the question would need to be investigated separately for each of those.

notheguyouthink 8y ago
Appreciate your insight!