When using Protobuf on a non-compressed environment, the requests took 78% less time than the JSON requests. This shows that the binary format performed almost 5 times faster than the text format. And, when issuing these requests on a compressed environment, the difference was even bigger. Protobuf performed 6 times faster, taking only 25ms to handle requests that took 150ms on a JSON format.
I suggest anyone who reads this comment read the linked article carefully. The difference is in a java-to-java scenario, and the specific task is retrieving 50k structured records.
If your data to be transported is heterogeneous, or one of your endpoints is JavaScript, or if your requests are gates by something else, e.g. bandwidth, transport latency, endpoint raw compute, or human interaction, this dramatic difference may not necessarily apply.
50K records in a single request is a highly abnormal situation, and we're still talking about only shaving 125ms off of the sum total time of that request. In most apps where something that crazy is happening, this is not a problem, as it's clearly in async batch territory.
In a realistic architecture where you need request/response, there's going to be a lot of network calls and database calls. In my experience, it's those DB calls where the largest opportunity to optimize is. The other opportunity is removing N+1 request patterns. A lot of these "Proto is faster than JSON" benchmarks are showing a throughput bottlenecked app, when most apps that need a fast response are concerned with latency, and serialization is often only a few percent of that.
> and serialization is often only a few percent of that
A few percent is a huge performance win. For example shaving 5% off the latency of twitter / facebook's apis is huge. Thing about the compute, energy and bottom line impacts.
I do agree for many protobuf is overkill, there's way lower hanging fruit that will give a greater latency reduction.
Here would be my honest response to that: are you building a Facebook/Twitter scale app?
I've watched quite a few companies waste a lot of time with static IDL systems for performance reasons (going back to CORBA in the 90s) and have had the exact opposite effect.
Facebook has Thrift internally but ultimately ended up building GraphQL because orchestration and parallelism was the limiting factor (they also need a giant amount of coordination glue code to map from Thrift to JSON anyways). Netflix had similar problems which resulted in them building Falcor.
gRPC-web, as well, needs this serialization hop step, so depending on your use case, it may actually be slower. The last two companies I've worked at were in the 50-300 services range with 50K+ business customers and in the 10M+ B2C consumer usage range, and in both cases the IDL translation case (gRPC in one and Thrift in the other) was slower than JSON for many of their applications. Not all cases mind you, but it was definitely hit or miss.
In regards to utilization as well, will the reduced overhead of server CPU utilization for protobuf return a higher ROI than the added engineering time of the solution vs something like Swagger codegen? Will the engineers' extra energy expenditure for their work ever make up for the (potentially) reduced servers? These are serious questions and I think a lot of companies waste a lot of effort and resources by not answering those questions honestly.
The performance advantages of a binary wire format are frankly just the cherry on top. The primary benefits of something like gRPC lie in having a programmatically consumable API spec that can turn your service calls into strongly typed RPC’s, and that benefit is a net gain in engineering productivity rather than a net loss.
You can get much of the same benefit with swagger codegen, though. It’s just that by the time you’re doing that, gRPC wouldn’t be that much more work anyway.
Incidentally, the dividing line between where programming languages are faster at handling protobuf than JSON, namely the dividing line between interpreted and compiled languages, is also the same one where you start to care about performance in the first place. And in Java or Golang, I’m not sure that gRPC is any more difficult.
Is swagger codegen a ton of work? I wrote a swagger codegen library for elixir (by hand) and that took a few weeks, but setting it up is basically three lines of code and a single mix command. Anyone else could use my library and be up and running in a hot second.
How often is often? It becomes more of an issue when you have more microservices because you might have multiple serialization/deserialization steps if you're calling a service that calls a service that calls a service, or if you're managing larger payloads.
