Updating an issue takes too long - Jira DC.

[Shachar Ovadia]

Hi everyone,

we have recently (last two months) upgraded from Jira server to DC. 

Right now, when updating an epic (and only an epic), it takes like 18 - 20 seconds to complete the update or creation.

Epic has some automations as script listeners, behaviors, scripted fields and WF scripts.,

but when disabling all scripts related to the epic it does not change the actual update / create run time.

I also created a new project based on the 'problematic' project's configuration.

When mapped all scripts to the new projects, it took something like 7 - 8 seconds to update, same scripts, same mapping, same configuration. 

I tried looking in the server logs and read over the internet to solve it, but no luck.

Any one has ever got into this?

Thanks. 

[Nic Brough -Adaptavist-]

What are your scripts doing?  Does it work more quickly if you remove them?

[Shachar Ovadia]

The scripts are not so quick actions, they are calculating fields and creating / deletes other issues based on some parameters., some of them creating bulk issues or deleting bulk issues as well.

As i said, I tried to disable all scripts and check the run time for update / create but the result looks the same. 

But actually i dig even deeper and found some logs of one script appears in another script's logs, that kind of odd isn't it ? 

[Nic Brough -Adaptavist-]

That's exactly why I asked - it's very likely to be all the automation and scripting you have added to it.

Plain Jira with no scripts or functions will be fast to create issues, even when there's a lot of fields to store.  The performance problems you are seeing are very likely to be down to trying to do a lot during the create process.

So that's why I'm suggesting you try turning them off and re-testing.  The problem here is that they don't all run from the same places.  And there's non-script stuff you can do that will be imposing load.

Let's concentrate on one of the examples you started with - editing an existing Epic.  Not creating or transitioning, as that simplifies what you're going to need to look at.  So...

• behaviors; Don't worry about them.  Behaviours run as part of the screen, they do not do anything during the commit of your changes.
• Workflow scripts; Similar, because I've limited the scope to "edit issue", there are no workflow scripts running
• scripted fields; ok, these are going to kick in, the scripts will run whenever you edit the issue
• script listeners; similar to scripted fields, if they're picking up the "edit" function

So, my guesses are now that you either have "fielditis", with way too many fields on your epics, or scripted fields and listeners are running, even though you think you may have stopped them.  

Next test would be to create a temporary project, with Epics, and make sure your listeners don't listen for that project and you deliberately don't give your scripted fields context for the project.  If these Epics create or edit quickly, you know it's that.  If they're still just as slow, then we know it's either the non-scripted fields on them or something else going horribly wrong.

[Shachar Ovadia]

Hi, 

Thank you so much for your reply,

Our all scripts is saved in the Script Editor, and listeners and scripted fields compile the script via the script editor,

Is it possible this is also a cause of a delay ?

[Nic Brough -Adaptavist-]

Scripts don't run or compile in the script editor, they run when they are triggered by the actions you have configured them for.

What happens if you create Epics in projects with no scripted actions or fields set up?

[Shachar Ovadia]

Well, actually it is so much faster when i execute an update or create.

Now I am trying to refactor some of the code related to epics actions.,

Some of the code contain for loop and nested loop like matrixes and so, so it kind of 'complex' i guess for the Jira host machine to process those calls.

What would you suggest for the next steps ?

Thanks.