Optimum Tuple-Field Allocation for Low Consumption

[Mehmed Aktas]

Hi,

Is it better to extend the fields across more tuples or concentrate the fields in less tuples for high performance Or doesn't it matter since moving "cost" of the data(total number of fields) is same

To clarify, I am giving an example. Think of the schema that my application enqueues as below:

Symbol(str), ID(str), NumberofEntries(list) (list contains 2 different price layers)

Should I parse the list by iteration as soon as I enqueue the data or keep the format and parse it whenever I need After parsing, the schema will turn into:

Symbol(str), ID(str), Amount(int), Side(int), Price(double)

and since the NumberofEntries list contains 2 items, it will make 2 different tuples after parsing.

Which option is more reliable for low latency Much thanks in advance.

[Steve Barber]

Hi Mehmed,

Thanks for the question.

Having given your specific question some thought, and having been on the receiving end of many such questions over many years, the answer I have will likely not please you but it is the only rational answer.

The answer is: it really depends on what you are doing and how you are doing it, and you should really be defining your critical performance metrics and targets for your specific application, creating and running your own repeatable performance benchmarks beginning very early in your application development lifecycle, and then optimizing only when you aren't hitting your targets.

It's also worth noting that the runtime implementation of things in StreamBase can vary significantly from release to release, so that anything I might tell you today might be different tomorrow.

In the specific example you give, consider that by definition a latency metric is a measurement of elapsed time from one point to another in an application (and that the definition of "application" is itself a rather fluid term).

I can imagine, for example, a situation where the multi-tuple design you mention has lower median latency from point A to point B say if A and B are operators in the same StreamBase parallel region but if you cross parallel region boundaries between A and B it might give you lower median latency if you effectively "batched" them by keeping them all in a list in the same tuple (because you are serializing tuples into and out of parallel region queues and also having to wait for the scheduler to process tuples in various parallel regions).

I would also as a general matter stay away from micro-benchmarks of various operations, and only benchmark the few end-to-end flows that are critical to achieving your business goals. Things like payload-to-tuple conversion in adapters and network hops in a cluster tend to dominate elapsed time versus just tuples passing through built-in operators.

I doubt this was the answer you were hoping for, but it's the only answer that in my experience will work out in the long run.