Custom Field Impact

[Viviane]

I would like to know the impact of performance in a very large field (35 thousand options). Is there a possibility  of creation?

[Viviane]

Hello Guys!!

Thanks for the informations.

[Radek Dostál]

You will have a problem trying to load the contexts page, and while I don't have any numbers (and didn't find them either), the list of options is actually cached - meaning everytime you do something with fields, the cache gets flushed which will start manifesting as slow instance.

I did suspect at some point that whenever you modify any option (in any field!), it flushes all option caches, irrelevant to the field you modified. Meaning if you have fields with so many options, any operations you do with fields will start degrading performance.

The problem is, I never digged that much into it, but if you tail your logs while you modify custom fields, it's pretty.. nasty all the caches being flushed.

You will probably live unless you do many of such fields, but it definitely won't be good to Jira and it will degrade performance in some way - how much and when is just a guess on my part, threads will start getting hanged, cpu will go up, etc., all things add to each other.

35k options in any way is a bad idea - imagine the size of caches and the size of options your browser would have to get and render - it will make the UI unresponsive to say the least. Either, split the data, e.g. cascading field, or, don't use an option picker. 35k is at a point where we're not talking about Jira even, we're talking about any service having to render and cache that much.

[Nic Brough -Adaptavist-]

@Radek Dostál is right in all of this.  You're going to have massive problems working with such a field. 

Every issue create, edit, view or transition screen with it on is going take ages to render as the server is going to have to hand over the list of every option on every load.  There is no chance of the admin screen ever loading so you can configure them.

Humans are never going to be able to work with such a list - we struggle with over 40 options in one list (some systems actively limit you to 55 because fields with more than that are useless to 99% of us)

Internally, the caching problem is not enormous, but it's not helpful.  Certainly anyone trying to use such a field will degrade performance for others while they try.

This, of course, begs the additional question - "Why?"  What possible use do you have for a 35k select list?

[Radek Dostál]

@Nic Brough -Adaptavist- is right in all of this. I could have english'd my first response better, but the fact that 35k options is inhumane is the better argument.

[Pavel Junek]

Hi @Viviane,

Welcome to Atlassian community :)

I don't think it's a good idea to create such a field. Jira with so many options will definitely have a problem. In addition, such a field is very poorly administered from an administrator's point of view.

I was wondering how you want to populate this field with options? 

Please look to similar question - Limit in the select (dropdown) values where is answer from Atlassian team.

Pavel