What
Currently the LoLa binding has some "performance counters", which basically supervise the event-slot-allocation/reference contention! I.e. the counters reflect how many retries were needed to either successfully allocate a slot (skeleton side) or reference a slot (proxy side). They also monitor how many times allocate/reference misses have happened (after N retries) - this is something, which would be also visible on user level API by getting an error from SkeletonEvent::Allocate() or ProxyEvent::GetNewSamples() - but these counters accumulate these events.
Here are the counters:
What needs to be fixed
The whole functionality takes place in the HOT-PATH! And it currently can't be opted out, although almost no-one uses these features as they are hard to access (see next point).
ALL these counters and related Dump/Reset-Functions shall only be available/exist in the code, in case a specific feature-flag is set/enabled!
Extension of counters
Think about othzer useful counters ... right now, they are only there for the inner allocation algo for event/field slots.
What about methods? Is there also something worth measuring? Service-Discovery?
Access to the Data/Resetting counters
There currently exist Dump/Reset-APIs for these counters. They can't be easily accessed (hidden deep down in the binding layer). We need an approach to make this public available in case the feature-flag is enabled.
Come up with a proposal for the API. Where shall it be placed? In the score::mw::com::Runtime ?
Maybe add a feature, that all the counters a dumped/written to log, when app shuts down? Maybe this is the easiest solution? Can be combined with explicit APIs to read-out/dump the counters?
How
See above - needs some concept work 1st.
Estimates for realization
2 weeks
Category
Requirements / Architecture
What
Currently the LoLa binding has some "performance counters", which basically supervise the event-slot-allocation/reference contention! I.e. the counters reflect how many retries were needed to either successfully allocate a slot (skeleton side) or reference a slot (proxy side). They also monitor how many times allocate/reference misses have happened (after N retries) - this is something, which would be also visible on user level API by getting an error from
SkeletonEvent::Allocate()orProxyEvent::GetNewSamples()- but these counters accumulate these events.Here are the counters:
What needs to be fixed
The whole functionality takes place in the HOT-PATH! And it currently can't be opted out, although almost no-one uses these features as they are hard to access (see next point).
ALL these counters and related Dump/Reset-Functions shall only be available/exist in the code, in case a specific feature-flag is set/enabled!
Extension of counters
Think about othzer useful counters ... right now, they are only there for the inner allocation algo for event/field slots.
What about methods? Is there also something worth measuring? Service-Discovery?
Access to the Data/Resetting counters
There currently exist Dump/Reset-APIs for these counters. They can't be easily accessed (hidden deep down in the binding layer). We need an approach to make this public available in case the feature-flag is enabled.
Come up with a proposal for the API. Where shall it be placed? In the
score::mw::com::Runtime?Maybe add a feature, that all the counters a dumped/written to log, when app shuts down? Maybe this is the easiest solution? Can be combined with explicit APIs to read-out/dump the counters?
How
See above - needs some concept work 1st.
Estimates for realization
2 weeks
Category
Requirements / Architecture