-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upload/Download performance with gRPC #1186
Comments
What do you mean by REST? REST usually that means JSON, and there is no streaming. I'm guessing that means the bytes being base64 encoded into one JSON response and the server returns that? I'm surprised that that would be faster than gRPC. |
I am most certainly miswording it when I am saying REST. What I mean is writing bytes to the output stream of the response of a GET request. I'll give a code example:
I am not sure yet if this is the proper way of implementing this yet but in my benchmarks it had a much faster performance than writing those same chunks to the
|
Writing raw bytes will always be faster and more efficent than gRPC. gRPC involves serializing and deserializing messages. That requires allocating buffers and copying bytes multiple times for each chunk of data. |
Indeed, as I was suspecting, there probably isn't much to be done here in order to improve the performance. I was hoping this wasn't the case such that I could use solely gRPC throughout my application. Anyways, thank you for the input! |
After doing some benchmarks between gRPC and REST (both
.NET 5
) for an upload and download functionality, the following results were obtained: REST had 2 to 3 times better performance for both upload and download than gRPC. Different sized chunks were used but none made any difference on the overall performance of gRPC when compared to REST. The benchmarks pulled data from memory in order to isolate the performance of both REST and gRPC from the data access latency.Eventually the conclusion that was drawn was that the protobuf serialization of each
DownloadResponse
is taking up most of the time of gRPC's streaming especially for larger byte strings ( > 1MB). REST on the other hand, simply has an input/output stream in the request/response and doesn't serialize the data it transfers.My question is, is there anything that can be done to improve the performance of gRPC when streaming files or is this not a great use-case for gRPC as a whole? I have come across some blog posts about using a custom marshaller but implementing it seems like a challenge and I do not know if/how it would resolve my problem.
Below is the very simple proto contract used for a streamed download.
The text was updated successfully, but these errors were encountered: