[META] Leverage protobuf for serializing select node-to-node objects

[finnegancarroll]

Please describe the end goal of this project

Provide a framework and migrate some key node-to-node requests to serialize via protobuf rather than the current native stream writing (i.e. writeTo(StreamOutput out)). Starting with node-to-node transport messages maintains api compatibility while introducing protobuf implementations which have several benefits:

• Out of the box backwards compatibility/versioning
• Speculative performance enhancements in some areas
• Supports future gRPC work

Initial protobuf implementation for types - FetchSearchResult, SearchHits, SearchHit

Edit: Closing this issue as we see only marginal benefits to utilizing protobuf on the transport layer. The existing writeTo() implementation is as performant as protobuf, if not more so. Adding a second implementation for objects sent over the transport layer would create a second parallel object which needs to be maintained and would only provide the backwards compatibility benefit of protobuf for that specific transport request.

Supporting References

• Search API POC - flame graph + OSB numbers
• Issue for API leveraging of gRPC + protobuf
• gRPC-based Search API

Related component

Search:Performance

[dbwiddis]

Having spent way too much time diving into the byte-level (or bit-level if you consider 7-bit Vints) details of these protocols, I want to make sure we're focusing on the correct things here.

Protobuf isn't some magical thing that brings about 30% improvement the way the POC implemented it, and I don't think the existing POCs tested it fully vs. the existing capabilities of the transport protocol if used properly.

In summary:

• I think most of the performance gain in the POC was based on reducing the number of bytes used to transmit information
  • Existing StreamInput/StreamOutput already contains the capability to use variable-length ints/longs, they're just underused
  • The existing Transport Protocol using Vint/Vlong is marginally (but likely not significant) more efficient (in bandwidth terms) than protobuf when dealing with unsigned values, and Zint/Zlong is equivalent to protobuf signed values.
• Broadly speaking, protobuf can be marginally more efficient in the case where there are a lot more "null" or "empty" values (you gain a byte in each case of a missing value, but lose a byte for every present value).
  • Protobuf needs to identify every field which takes a byte; StreamInput/StreamOutput need an boolean to implement optional.

Protobuf's primary benefit is in backwards compatibility.

There are probably additional significant benefits of gRPC but this meta issue doesn't seem to be about changing the entire protocol, so I don't think those should be considered as part of the benefits proposed.

The performance impacts are very situation specific and shouldn't be assumed; it's possible a change in streaming to variable-length integers/longs (VInt/ZInt) can achieve similar gains.