----
Josh Humphries
FullStory | Atlanta, GA
Software Engineer
--
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 grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/26219adc-254e-4dc2-82a0-2b7f9513d41a%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to grp...@googlegroups.com.
Thx Josh for the reply.let me clarify1. I'm sending 100 MB+ string as bytes type with protobuf, so what the server side is doing in the streaming case is, preallocates a size of 100 MB+ (size info provided from the first streaming message) and keep appending the broken up bytes sent through streaming rpc to it, after collecting and appending all the bytes, it will respond. For unary, once it receives the whole string, it will respond. So I would rather say the server is more like a no op than it is preprocessing the data.2. It is not a load test setting, both client and server are sync with single thread. No compression is used."Depending on the runtime implementation, there could be an advantage just due to pipelining: it's possible that your handler thread is handling unmarshalling of a message in parallel with a framework thread handling I/O and decoding the wire protocol. Whereas with a unary call, it's all handled sequentially."This sounds very interesting to me, I would like to see where it actually does this pipelining, do you have any reference code? Thx Josh!
To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/e53109a4-b910-4e9c-b2f7-dda48e6deb5c%40googlegroups.com.