A timeout may be implying that you simply have too large a backlog for your server to cope with.
Could you tell us what the board filter is (in plain text, don't give us screenshots, just copy and paste the text and feel free to change any names that you don't want to tell us). We're looking to see how big the filter might be.
Or, try changing it to include a smaller range and see if the timeout problem goes away. Add something like "and created > -7d" to it temporarily to shorten the list.
One more important question is that in my organization around 80 users are working concurrently. and 30000 issues are there and it growing fast from few days.
So users facing some performance issue. They want more response time. I already increase JVM memory upto 4 gb. now from that only 1gb memory is used by JIRA. Code cache memory and Metaspace memory is almost full so what is exact problem behind this issue. Tell me the solution.
Scaling JIRA is a totally different question (all I'd say there is "throwing memory at it randomly is not a good answer"). 30,000 issues is still a "small" installation in my experience though - I'd have a look at the "growing fast" bit first and get an estimate on the rate of growth - how many issues do you expect to hit by year end 2016 and 2017 for example.
Anyway, back to the question. A couple of follow ups:
45 issues returned by "project = x" should render almost instantly.
I'm afraid you're going to need to do some deep analysis on what exactly is wrong with your system.
Are there other places where you get very slow or timed-out page loads?
You'll need to check the front-end - start by using something like firebug or developer tools to work out which parts of the backlog view are taking time to render.
You should probably check the network, although that's easy - is all the system slow or just specific screens? If it's just certain screens, it's not your network.
You definitely need to check the back end - is the server overloaded? What does the log say when you try to render the backlog? Can you get a thread-trace?
If you can't render 45 issues, 26k is not going to happen. Plus it's a silly number that your humans won't be able to cope with either - you need to break it down into sane sized boards.
So, you need to go back and do the analysis on what the server and client are doing, to work out why they're slow.
I have multiple projects that use variations of the same base workflow. The variations depend on the requirements of the project or issue type. The variations mostly come in the form of new statuses ...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs