The post is related to this one:
The recommendation to create a configuration with 3500 "old" components via one catch-all Jira projects and corresponding number (3500) of Jira project components was implemented. Yet, the results (as far as Create Issue performance is concerned, at least) were even worse than when all 3500 components were created as separate Jira projects. Now, after a click on Create Issue link, about 20 seconds elapse before a dialog is opened. Autocomplete search for component works well, but submit operation (Create button) takes another 5-7 seconds. For comparison, when an issue is being created for Demo project in the same Jira instance, it takes about a second for Create Issue dialog to open and about the same time to submit. Again, this is pretty much a vanilla Jira installation - no custom fields, no customized workflows, permissions, issue types. Only users (~1000) and components (3500) are created for a single catch-all project
Can someone, please, tell me what is going on in Jira (what kind of checks and validations) before Create Issue dialog is opened and why it might take such a considerable time to submit it (only component and summary fields are populated besides issue type and project). Note that the delay was about the same (close to 20 sec) when a project was changed from Demo to catch-all one (with 3500 components) inside Create Issue dialog
I would be very much obliged for any recommendation to tune this configuration so as to reduce/eliminate this delay
Thank you very much
The obvious answer is the amount of data passed to the browser to initialize CreateIssue screen. In case when I had 3500 components and 9000 versions, it amounted to ~2MB of data passed every time I clicked CreateIssue or changed a project. Depending on the network latency, server and client machine resources, that resulted in 10 to 20 seconds delay.
It remains a mystery why Jira needs to pass this whole configuration to the client. The alternative may be to use database searcher plugins (such as nFeed) but that would necessitate forfeiting all basic built-in Jira fields (such as versions and components) and replacing them with custom ones...
One obvious answer is the amount of data passed to the browser to initialize CreateIssue screen. In case when I had 3500 components and 9000 versions, it amounted to ~2MB of data passed every time I clicked CreateIssue or changed a project. Depending on the network latency, server and client machine resources, that resulted in 10 to 20 seconds delay. Most of the passed data consisted of the list of components (all!) and versions
It remains a mystery why Jira needs to pass this whole configuration to the client. With the autocomplete renderer attached to these fields (Component and Versions), it should not be a case. Yet. HTTP dump clearly shows ALL of the components and versions passed to the client during the initialization and POST
Looks like default autocomplete renderer simply does not use Ajax and filters all the data on the client side
Is there any way to override this behavior and not send this amount of data back and forth? This kills performance...
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Heya, Hipchat friends! We’re so happy you’re checking out Stride. Whether you know it or not, you have been instrumental in making Stride come to life. Every feature, design, and functionality...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG