From my point of view there should be no difference in the AHT of these two?
If I multiply the AHT of either, with the number of items, the total time ends up on about 17,5 days.
Only problem being the oldest item is about 4 days old and the process is done
So i donβt know how the calculation is done but it is wrong from what i see
I know we had issues AHT and such not updating at one point, but i talked to server admins and they found a script not running (it have been fixed months ago). Now the AHT is updating fine, so my conclusion is that this must be a bug in Orchestrator 2019.10.15 that we are running?
@loginerror can you ask internal if we can narrow down somehow what is causing this. Because while running the time seems to be correct, but after queue finish the AHT is way off, and for any run after the first, the AHT is no longer correct.
I suspect thereβs an outlier transaction that skews the result. To verify the result accuracy, you can run a query on the items for that specific queue, something like: SELECT AVG(CASE WHEN Status = 3 then CASE WHEN DATEDIFF(DAY, StartProcessing, EndProcessing) > 0 THEN DATEDIFF(SECOND, StartProcessing, EndProcessing) ELSE (CAST(DATEDIFF(MILLISECOND, StartProcessing, EndProcessing) AS DECIMAL) / 1000) END ELSE NULL END) AS SuccessfulTransactionsProcessingTime FROM QueueItems WHERE QueueDefinitionId = <your Queue Id>
If this matches the displayed result, then we can sort QueueItems by their SuccessfulTransactionsProcessingTime and find the outlier(s). Something like SELECT TOP 5 (CASE WHEN Status = 3 then CASE WHEN DATEDIFF(DAY, StartProcessing, EndProcessing) > 0 THEN DATEDIFF(SECOND, StartProcessing, EndProcessing) ELSE (CAST(DATEDIFF(MILLISECOND, StartProcessing, EndProcessing) AS DECIMAL) / 1000) END ELSE NULL END) AS SuccessfulTransactionsProcessingTime, * FROM QueueItems WHERE QueueDefinitionId = <Queue Id> ORDER BY SuccessfulTransactionsProcessingTime DESC