nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

JIRA Scale Up Strategy

Michael Garvin

Hi, our company is now considering if JIRA can be used to consolidate all of our companies issue tracking tools into JIRA and JIRA alone. We think this would be a great thing to do, but we know that in doing so we would ramp up the number of active users and JIRA issues quite significantly, going from a few hundred active users all the time, to thousands of active users all the time.

Before we do any consolidation, we want to be sure we've planned ahead for how to keep JIRA perfming as well as it does now, after we have millions of issues in the database and thousands of active users.

Have any you done this kind of scale up at your company? What are the gotchas's to watch out for? Is it as simple as partitioning JIRA (creating a functional bubble for JIRA, Bamboo, Crucible and Confluence), and just creeating as many bubbles as you need?

Ultimately, is it cheaper/easier to just allocate bubbles through Atlassian hosting? We like having customizations and integrations we have now with stand along tools, I really fear how much we would loose by going to a hosted solution, but maybe it ultimately makes more sense to allocate bubbles through hosting?

If you've gone through this exercise at your company, could you share your experience? I woiuld be very interested/thankful, to hear about how it went, and what the pitfalls are.

Thanks in advance for your time/learnings!

Please feel free to reply here or email me directly. (mgarvin /at/ avaya.com)

Thanks!

Michael Garvin

Avaya.com

Accepted answers

Michael Garvin

The support team at Atlassian put together a great FAQ on this, it covers the bases prettey well, except for concurrent usage:

https://answers.atlassian.com/questions/22210/jira-scale-up-strategy

All comments

SimonS

Hey Michael,

Your request is actually pretty common and to be honest, we do a terrible job telling you guys about how to scale JIRA.

We recommend splitting JIRA instances once you reach around 20,000 issues. This works, but it isn't a hard limit - you should be able to run JIRA with a million issues!

I think you would be interested in an article by Spartez (one of our partners):

https://loft.spartez.com/confluence/display/SPARTEZ/Testing+a+Million+Issue+JIRA+-+The+Verdict

Hope it helps, and let us know if you have any more questions about scaling JIRA.

-Simon

Michael Garvin

Thanks! Thats very cool, they even include source for how to simulate whatever load you are targeting.

I also reviewed:

http://forums.atlassian.com/message.jspa?messageID=257322346

and in talking to Atlassian support, they said that JIRA 5.x will have a much better Luceme engine, so that shoudl help as well

Michael Garvin

This seems like exactly what we need:

http://www.sourcesense.com/en/events/scarlet.html

is it too good to be true?

Seems like it should work and the actual source patch is free, but I guess if you can't get the current version of scarlet to work with your current version of JIRA, you'd have to go back to sourcesense to get their help in bringing scarlet up to date, so clearly your upgrade velocity would be at risk. But if you patching source JIRA...maybe you should update less often anyways

justindowning

I think you meant 200,000 issues, not 20,000. ;-)

Michael Garvin

The support team at Atlassian put together a great FAQ on this, it covers the bases prettey well, except for concurrent usage:

https://answers.atlassian.com/questions/22210/jira-scale-up-strategy

Andrei [errno]

the link provided points to this same page

Andrei [errno]

the links provided points to this same page

Michael Garvin

Hi, yeah this posting is out of date...but actually since then we have complete dour testing on JIRA 5.0, and we took it up to 1M issues with 10K users and had no problems. Ofcourse we used some big hardware to test, but basiclaly JIRA scaling is no longer an issue from what we can see. Although, we agree with other people that its a very good idea to put the database (we tuned with PostgreSQL) and the Lucene indexes on an SSD drive. For testing we just used Ramdisk (since its so easy to create on linux -- just make a tmpfs folder).

We wrote a bunch of PHP scripts similar to the the Spartes folks, doing all the same kinds of operations to test throughput on issues. Basically we found there is a periodic "bump" due to Lucene; text search response time exponentially explodes at 600K issues, 1.6M issues, etc. But to get that "bump" we had to run JIRA with 40Gb memory and 24cores *all* running flat out at 100%. To get to that level of overload, we'd have to hve hundreds of times more traffic than we do now (orders and orders of magnitude).

So pretty much, JIRA 5.0 scales no problem from our point of view. Atlassian alaso has someone working on proper enterprise level support, if you just ask them for that contact, I'm sure they can get you hooked up.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

performance

scale