Significant delays in Create Issue dialog

[Dmitry Nechayev]

The post is related to this one:

https://answers.atlassian.com/questions/118259/pre-populate-project-field-in-createissuedetails?page=1

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

[Dmitry Nechayev · Accepted solution]

Looks like a comment above is an answer.

[Dmitry Nechayev]

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...

[Dmitry Nechayev]

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...