Closed KonradBkd closed 1 month ago
@KonradBkd I think it would be better to add an additional metric that measures the completion duration in contrast to the execution duration. Both measurements are interesting, e.g., async sim. step handler is taking longer than expected due to lock contention.
@KonradBkd I think it would be better to add an additional metric that measures the completion duration in contrast to the execution duration. Both measurements are interesting, e.g., async sim. step handler is taking longer than expected due to lock contention.
You're right, we should measure both and should be precise with the terminology. I'd say a LogicalSimStepDuration
spans from the invocation of the handler until
CompleteSimStep
Whereas, the SimStepHandlerExecutionDuration
is just around the handler in both modes.
Or, as you suggested, we the split in handler execution time and completion time.
The issue came up when looking at the output by Trace(_logger, "Finished Simulation Step. Execution time was: {}ms", executionDurationMs.count());
, which is kind of misleading (because too small) when using the SimStepHandlerAsync.
Subject
SimStepHandlerAsync
, because the simulation step is actually not finished.Description
SimStepHandlerAsync
, the Log Message "Finished Simulation Step. Execution time was: ..." is now printed after the call toCompleteSimulationStep
.SimStepHandlerAsync
, the new metric SimStepCompletionDuration measure the interval between the end of the handler and the call toCompleteSimulationStep
.Developer checklist (address before review)