You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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?
What are your scripts doing? Does it work more quickly if you remove them?
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 ?
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...
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.
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?
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 ?