JIRA Performance degrades significantly for a short time after editing any custom field if you have a lot of custom fields

Basically when you edit a custom field you invalidate all cached field configuration. This means that it has to be read from the DB again and re-cached. Unfortunately, JIRA will read the configuration for each field individually which can lead to many (thousands) of SQL queries and slow page loads for people using JIRA after the configuration change.

For example. I have and instance with 558 custom fields and 771 field configurations. If I edit the description of any custom field these are the >2500 queries (you may need to scroll to see the query count column) that JIRA runs to just show the custom field list.

If I then goto the issue navigator I run the following queries.

This time well over 3000 queries are run (again you may need to scroll to the right to see the column). If I then re-load the issue navigator then no SQL queries are run because things are now cached.

This number of queries can cause significant delays even on very fast database servers. Some pages can take 5-10 seconds to load after a field configuration change. This causes significant pain to users who change their field configuration regularly.

Maybe JIRA should be eagerly loading the cache (i.e. all the configuration for all the fields in a single query) rather than lazy loading it (i.e. lots of queries per field configuration) as the configuration will be used in most operations in JIRA.

This problem does not appear to be fixed in 4.1 (maybe it got worse). Check out the ~2000 SQL queries executed to view the "Custom Field Page" after changing a field description.

Further, notice the the ~4000 queries executed when viewing the issue navigator for the first time after the description change.

Again if you then view the navigator again no queries are run as all the information is cached.