Wrong timing in automation for Jira tasks

[Siavosh Kasravi]

I have a groovy script that runs on multiple scripts in fixed time intervals.

The problem is the time recorded for each run is at least ten times bigger than the real wall clock time it has taken. For example a task stays in progress for ten seconds and the time shows in front of it is 140s. This causes the service limits to be hit and tasks throttled. Any idea why it might happen?

[Deleted user]

Hey there Siavosh,

Is your rule working on multiple issues? The duration you there is a summed up duration (the processing time), so if your rule is a scheduled rule that runs across multiple issues, then the duration will be more than the clock time.

If you're on server, you can adjust your service limits (see https://docs.automationforjira.com/knowledge-base/service-limits.html#increasing-service-limits). They're there to protect you from accidental over-use, but if you're clear on what loads and limits you need, you're free to adjust them.

Hope that helps!

Cheers,

Mark C

[Siavosh Kasravi]

Well. Of course it is running on multiple issues. But, if it runs the script for the issues concurrently and sums up the time for each one, I believe it will result in irrelevant values as duration time. You see the goal is to prevent automation tasks to consume resources more than a specified time. Now suppose my script utilizes server CPU 100% for each issue. In this case which issues couldn't be dealt with in parallel obviously, the real time my task takes to complete for all issues will be equal to clock wall. In this time span my task really took all the CPU time. So my first point is in no way the time span can be more than wall clock time. In practice my tasks will utilize very little CPU and are waiting for HTTP request responses most of the time. So the CPU utilization time should be recorded instead, to give a relevant value for resource use restriction purposes.

Actually we did decrease the service limits but it is a bad practice as it has no meaning to have more than 12 hours run-time permission in 12 hours and renders the control useless.   

[Deleted user]

Hey there Siavosh,

sums up the time for each one, I believe it will result in irrelevant values as duration time

Yeah it's a fair point of view. We were discussing it internally about what to display to the user here. We track both end to end time as well as total processing time, but decided processing time makes more sense since that's what the limits are based on.

my tasks will utilize very little CPU and are waiting for HTTP request responses most of the time. So the CPU utilization time should be recorded instead

Again a fair point from that angle. In an ideal world, tracking CPU / resource usage for the Automation threads would be useful. Doing this in a cross platform way and narrowing to just the Automation threads is tricky, so we use the time spent running the rule as a proxy for utilisation.

Actually we did decrease the service limits... more than 12 hours run-time permission in 12 hours 

The idea of the service limits for Server is that you can adjust it to match your usage and infrastructure conditions. If you're happy for your infrastructure and your rule limit processing time to be greater than clock time, then you can tweak the settings. 

Let us know if you have any more questions / suggestions! 

Cheers,

Mark C

[Siavosh Kasravi]

Well, showing the time which limits act on is reasonable. But limits should be based on wall clock and even this approach is conservative as it doesn't give the real resource utilization.