Table of Contents | ||
---|---|---|
|
How powerful
...
server do I need for my company?
Since our plugins work with Jira, the first thing to consider is the Jira Sizing Guide. The additional footprint our plugins add is difficult to estimate due to the various possible configurations of modules and functionalities that can be used. 20 to 30 percent more powerful servers should be safe to assume if you want to ensure comfortable interaction while working with our plugins.
Info |
---|
We do not support HSQL and H2 databases. The plugin should work on them, but some bugs may happen and we cannot guarantee a smooth experience. The recommended databases are MSSQL, MySQL, PostgresSQL, and Oracle. |
Maximum number of Jira issues loaded into a single BigPicture
...
box
To begin with, performance and load tests executed by SoftwarePlant BigPicture have set the threshold range of issues possible to present by a single BigPicture Box to 5000 issues20,000 to 30,000 issues, depends on number of simultaneous users.
We are constantly working on performance improvements, so don't hesitate to contact us and let us know if you experience any problems with using BigPicture on a larger scale.
...
When it comes to responsiveness, the end-user PC hardware has an impact. Having an updated Chrome, Safari or Firefox browser on a modern PC (dualquad-core PUCPU, preferably at least a Sandy Bridge an Ice Lake series for Intel and at least 2 GM 8 GB RAM, preferably 3-4) is advised.
For the following table, notice that the order is not exact because Clocks are listed to give an idea of specific workload requirements. With the same clock number, obviously, an i5 will be more powerful than an i3. This is actually more of a matrix than a table.
Batch size | Clocks | Recommended |
---|---|---|
50 | 100 | Pentium Dual-Core |
50 | 20,000 | Core i5-class CPU |
500 | 100 | Core i3-class CPU |
500 | 20,000 | Core i7-class CPU |
The figures above are for Sandy Bridge and newer generations of Intel CPUs. Equivalents for AMD and other manufacturers vary, it is best to consult your server provider or an administrator.
16) is advised when you use BigPicture with small amount of data.
BigPicture performance tests conducted by
...
Appfire
SoftwarePlant Appfire performs load and performance tests before each release to maintain the optimal user experience of BigPicture.
Details of Jira environment used for performance tests:
Operating System: Linux
Database: PostgreSQL
Jira RAM: 1536 MB - for plain Jira and BigPicture
CPU of the host server: 8 cores - host server manages the CPU allocation
Jira server memory setup comfortable for BigPicture
The general rule of thumb is to preserve 4KB of RAM memory for each Jira issue registered in the system. This conversion formula includes overhead which is generated by BigPicture entities that accompany BigPicture tasks (which are entities wrapping Jira issues).
...
Medium-scale users (every node): 4 CPU / 16 GB RAM
Large-scale users (every node): 8 CPU / 32 GB RAM
XLarge-scale users (every node): 24 CPU / 96 GB RAM
Example sizing
Metric |
|
|
---|---|---|
Medium-scale | Large-scale | |
Issues | 150,000 to 400,000 | 400,000 to 1,000,000 |
Projects | 200 to 500 | 500 to 1,500 |
Users | 1,000 to 10,000 | 10,000 to 100,000 |
Custom Fields | 250 to 500 | 500 to 1,500 |
Workflows | 80 to 150 | 150 to 500 |
Comments | 250,000 to 800,000 | 800,000 to 3,000,000 |
Permission Schemes | 25 to 100 | 100 to 300 |
XLarge-scale means more than Large-scale range in any metric.
Info |
---|
To improve the performance we recommend , please consider increasing the JVM to at least 512MBmemory. |
Hard drive space required
Modern servers usually have usually enough storage space to accommodate Jira and plugins without problems. Plugins themselves are marginal size by modern standards:
BigPicture is approximately 62MB141 MB
BigGantt is approximately 44MB140 MB
BigTemplate is approximately 68MB 177 MB (additionally consider custom templates that you wish to upload)
...
Backups - we recommend backing up your instance before every update (your Jira data size is the key concern here).
Logs - storing logs makes sense only for a limited period of time and usually , the default settings are OK.
Example sizing
For a Jira instance with 1,7m Jira issues, 650 Custom fields, 185 issue types, 185 workflows, 2500 users.
For issues, always remember about the 4KB per issue rule of thumb.
All 650 custom fields can be used in a Box Column Views configuration. The number of columns directly impacts the BigPicture performance and Gantt loading speed.
Issue types, workflows, and users do existing in Jira instance does not influence the performance of BigPicture.
...
Each synchronizer adds additional work performed for every Jira issue in the scope of a Box. If you configure your Jira based on best practices as described above in Jira Sizing Guide and BigPicture described in this document, it will ensure successful implementation of BigPicture into your environment.
FAQ
"Are there any special configurations related to performance, is it possible to maybe reserve more threads for BigPicture? Or similar..."
Here are some tips that might help:
Use date filtering if your Box spans a long period of time
Switch off Fine-grained logging
Do not use complicated JQL queries in the program scope and filters
Increase the Synchronization time interval
Change the Box status to closed
Switch off the statistics collection and Feedback button
The more data fields such as columns on Gantt you show while using BigPicture Plugin the more time it takes for the browser to calculate and render it.
Switching off the WBS Widget on the detailed issue view should improve the loading time of the issue.
Limit the number of tasks in the program as mentioned in the chapter Maximum number of Jira issues loaded into a single BigPicture module.
Consider configuring a custom database connection for the plugin
Limit tasks loaded each time a program is opened. Note though that all aggregation calculations will only take into account loaded tasks only.
Remember that each additional plugin installed shares Jira's resources
Archive old projects. Here's a link to the official Atlassian Knowledge base article on the topic
Disable the "Save task changes to Jira issue page"
Disable widgets and live synchronization
Remove the Boxes you do not need
Do not map individual fields
Make sure that your browser does not block caching
Improve app performance
Support is always there to help
In case your needs are more complicated, you are always welcome to contact our helpful Support Team. They are always more than happy to answer all inquiries.