Having Jira + BigPicture performance issues? Let’s break this into pieces. What does affect performance and what can you do to improve speed?
Most of the below tips pertain to the on-premise hosting, i.e. Jira Server and Jira Data Center. Scroll down, though, and we touch BigPicture Cloud, too.
BigPicture Server and Data Center – golden rules
- Update! Each new version of BigPicture is faster than its predecessor
(one exception is mentioned in the ‘Versions’ section below).
- Observe BigPicture sizing guide. Have 1GB of RAM on your server for every 100.000 tasks.
- It’s the so-called initial synchronization that slows BigPicture / BigGantt. The initial sync happens when a Program hasn’t been accessed by anybody in the last 24 hours or more. The sync has nothing to do with closing or not a browser’s tab or the browser itself. Even if everybody close their browsers, but some user reopens it later to access the program within 24 hours, the initial sync should not take place.
- — I have more than 50.000 tasks in a single BigPicture program. Could that be causing a performance issue? We hear this a lot, but more often than not this doesn’t cause performance issues. BigPicture was designed for 100.000+ tasks per program, virtually for an unlimited number of tasks.
Gantt chart and Roadmap
Ok, so far we’ve discussed the server-side issues. Now, the Gantt chart and the Roadmap modules are also prone to the client-side performance issues, namely those that happen in your browser. We recommend that:
- users work on (1) Chrome or (2) Firefox browsers
- a Jira + BigPicture admin limits the number of tasks that can load simultaneously. Take a look at the screenshot below for directions.
Starting 19th June 2019, users of BigPicture/BigGantt Cloud see a performance boost, as we migrated the cloud versions of our apps from one to three reliable and powerful servers.
Understand what BigPicture versions mean (and why it has to do with performance)
BigPicture / BigGantt versions meaning
X.Y.Z format stands for:
X – product line, new components have been added, etc.
Y – new feature(s) have been added
Z – bug fixes, minor improvements, including the speed-related ones
Examples: BigPicture 7.1.4, BigGantt 3.14.7
You might have heard to keep your BigPicture and BigGantt up to date. Yes, it’s better to have BigPicture 7.5 than BigPicture 6 when it comes to speed and functionalities, but there is a thing. If you’re particularly sensitive about software reliability and performance, keep in mind that the higher the ‘Z’, the more stable a version tends to be. For instance, 7.0.5 is likely fine-tuned compared to 7.0.0. This is because the second number represents new features and the third one stands for bug fixes and minor improvements, including the performance improvements that relate to the newly added features. Two weeks from a major release is usually enough for us to fix possible performance issues, if any at all.
So if you are a Jira admin for a large organization with hundreds of BigPicture users and you are on, say, BigPicture 7.2.6, and you’ve noticed BigPicture 7.3.0, and even more so 8.0.0 available from Atlassian Marketplace, plan to spend more time in your test environment.
Jira Server vs. Data Center
It may seem counterintuitive, but BigPicture Server is slightly faster, by dozen or so percent than BigPicture Data Center. And it is true with 99% of third-party apps available from Atlassian Marketplace, even though Atlassian has developed Data Center with performance in mind.
Jira Data Center, however, is big on scalability, i.e. it can serve more requests at a time by a larger number of users. That said, it takes Jira BigPicture that dozen or so percent more time to take care of a single request on the Data Center hosting. Nevertheless, the Data Center cluster of servers is capable of serving more user requests simultaneously.
Have the above guidelines brought the performance gains to your Jira + BigPicture instance? If not, turn BigPicture’s ‘Monitoring’ feature on. Go to ‘Technical info’ and press ‘Start’ next to these:
- Cache monitoring
- Locks monitoring
- Endpoints monitoring
Then get the log files by pressing ‘Statistics’ buttons, and e-mail them to email@example.com or just contact us with your own intelligence and screenshots. We’ll try to solve your performance issues.
Should you analyze these logs on your own? You can do the following:
- enable the monitoring periodically, say once per month or quarter
- accumulate these logs
- if performance issues arise at some later point you can compare the logs from, say one year ago to the current ones
- now you are able to tell whether it’s the number of tasks in your system that affects the execution times
Still having performance issues?
Get a more in-depth understanding of what affects Jira + BigPicture speed here: BigPicture performance docs.