service design proposal: batched sampling

[LimeHat]

Considering that gNPSI is expected to have relatively high messagage rate, and a low avg. message size, our team would like to propose the change that allows performing batching on the server side (instead of having to stream back each individual sample).

message Samples {
  repeated Sample samples = 1;
}

In the general case, this will allow implementers to have better control over streaming and should allow to achieve better performance at least in some cases (various grpc library implementations have different ways of working with write() syscalls, YMMV).

[marcushines]

i am not clear why this is considered to be a good change
the problem with adding this option is now you have to worrry about the size of the batches and i am unclear how this signifcantly improves performance?

[LimeHat]

now you have to worrry about the size of the batches

can you elaborate on that? are you talking about server-side or client-side?

and i am unclear how this signifcantly improves performance?

by default¹ sending each message implies a write() syscall which is an expensive operation and in the past we've seen bottlenecks in this area. and only 1 write can be active at a time for each stream. We'd like to have an ability to reduce the number of writes in the server code, and, based on our experience, this allows to achieve better performance.

Footnotes

1. this is not neccesarily true for all grpc libraries; e.g. in golang, AFAIR, grpc-go performs a transport-level buffering/batching before doing a write() to the socket. but that's not the case with C/C++ grpc lib for example. ↩

[LimeHat]

As an extra note, this is not a novel or unique pattern. In OC world, for example, it is already used with gNMI and gRIBI streaming services