Jama Software Performance in the Enterprise: Recommendations for Jama Software Admins

By Eric posted 10-19-2015 19:43


How to Approach Large-Scale Jama Software Usage

This article is intended to help organizations with large deployments of Jama Software optimize the performance of the system. You can ensure your end users have a good experience while using the application by understanding and adopting recommendations about Jama Software’s usage parameters. This guidance is based on what we’ve learned as a result of years of working with our largest customers and our own performance testing.

What Does “Large-Scale Jama Software Usage” Mean?

Customers with dozens of teams and thousands of items generally experience excellent performance using Jama Software. Large enterprises with thousands of users, millions of items, and many complex interactions will need to take into account some additional considerations to achieve optimal performance. There are several key factors that can influence the performance of the system, including:

  • Hardware (System Recommendations)
  • Number of users actively using the system at one time (Concurrent Users)
  • Total number of users in the system (Active Accounts)
  • Number of items
  • Structure of items (number of relationships between items; the number of items per project; depth of hierarchies)
  • Number of resource-intensive reporting, publishing, copying and reuse activities (high load activities)
  • The number and/or frequency of integrations, number of items being synced and frequency of sync 
Jama Software can be configured to support many different data structures and usage scenarios. One customer may have no trouble with ten million items in their database; another customer on identical hardware may experience degraded performance due to how they’ve linked items together. System specs that work for one customer may not work as well for another who adds frequent high-load activities during high use times.



Jama  Software provides production system requirements that should be monitored as your company scales. The recommended Enterprise hardware configuration specifies at least 32 cores of CPU, 32 GB of memory. Many other enterprise tools manage flat lists of items, but Jama Software data is deeply interconnected and therefore requires more resources.

The more complex and linked your data structure, the more related items you will pull into memory, and the more processor-intensive it will be to manage. We require that the application server is on a dedicated system with no other applications running, with a separate dedicated system for databases. It is acceptable to share the database server with databases for other applications.

Number of Items Per Instance

Depending on your complexity, 5 million active items and 25 million total items (including archived) is a reasonable maximum per instance of Jama Software. We have some customers who exceed these numbers successfully, but these are the baseline levels for our performance testing.

As the number of items increases in a Jama Software instance, it will take longer to re-index. You will need to plan for longer maintenance windows over time.

Number of Concurrent Users Per Instance

Jama Software can support instances with thousands of active users, however, performance may decrease if you have more than 150 users in the system at the same time. Volume can lead to performance issues when high load activities are also being performed. Thousands of user groups may also cause slowness due to the permission checks required of the system.

Project Size

Jama Software maintains a numbered list of all items in the project. Item inserts and moves will trigger a renumbering operation, so we recommend limiting projects to 25,000 items or fewer. We’ve observed that renumbering is fast enough for projects with thousands of items but slower for projects with tens of thousands.

The Project Explorer tree setting ‘Max items displayed in explorer tree’ should remain at 250 or fewer items. This decreases the number of items displayed in the tree for very large folders, components, and sets. Work can continue with the whole set in the list view on the right.


Excessive use of certain capabilities within Jama Software can generate taxing loads on the system. With 2015.2, Jama Software provides a System Health Report to help your administrator identify usage that may be reducing your system availability so you can reach out to those users.


The Reuse feature in Jama Software clones existing items within or across projects. During the reuse operation, items involved will be locked and others will be unable to edit until reuse is complete.   Reusing hundreds or dozens of items is a modest-load activity.  Reusing thousands, tens or hundreds of thousands of items generates a lot of loads.  Consider running large reuse operations during off-hours or low load times.


The more you use to sync with reuse, the slower that edits will update synced items. As you update a single synced item, Jama Software will run a comparison to all items synced to the edited item. Avoid syncing thousands of items at a time.

Avoid chained reuse and sync. If you need to reuse an item multiple times, always start from the original item. Similar to reuse, Jama Software will lock items while performing sync. To avoid locking users out and slowing performance, consider running large sync operations during off-hours or low-load times.


Reports with thousands of items generate very high load and high memory consumption. They also can take a very long time to complete, which destabilizes the system if they are run concurrently with other high load activities.

Consider splitting large reports into smaller documents if they must be generated frequently, and consider generating very large reports during off hours. The System Health report in Jama Software can help you identify which reports are taking a long time to run.

Large Reviews

The Review Center was designed for reviews of up to 250 items. Reviews with thousands of items are not recommended. If you create larger reviews, they will perform slowly and generate high load. We have substantially improved the performance of the Review Center with the 2015.2 release, and we intend to continue to increase its capacity to handle larger reviews.


The deeper you set permissions in the tree, the more computationally intensive it is to check permissions. Where possible, set permissions at the project level or at one or two top-level components or sets.


Jama Software was designed to create and manage manual tests, assuming hundreds of items, yet customers are using Jama Software successfully with millions of test cases. Maintaining optimal performance depends on how the test cases are managed.

Test plans with more than 1,000 items and hundreds of test groups may cause Jama Software to perform more slowly. Consider breaking your test plans into multiple smaller plans. Relatedly, the Jama Software application interface for editing test cases is designed for manual test volume. However, you can connect Jama Software to an automated test system. If you are inserting more than 10,000 test definitions via the API, it is best to manage those definitions through the API.

Be thoughtful about how much test data you are inserting automatically through the web services API. For example, adding automated nightly test results to 100,000 test cases, you will quickly exceed the recommended system volume.

Relationship Configurations

Jama Software’s traceability and coverage views will support hundreds of relationships per item. Although the Jama Software server will store very complex networks of relationships, the interface is not optimized to display massive graphs. Retrieving a broad and deep hierarchy from Jama Software quickly can generate long-running transactions, which will reduce availability for other users.

The Trace View is designed to show thousands of related items loaded incrementally as the user navigates, allowing relationship data exploration. Due to the live and dynamic nature of the view, the volume of data the browser and Jama Software must concurrently track may be very high. The number of visible items in Trace View depends on the data structure being explored, which was tested to roughly 6000 related items. To view traceability for large-scale data, it is recommended to filter the data in a List or Reading view before activating Trace View.   


Integrations can run quickly and generate a lot of load by constantly polling Jama Software’s API. Leverage Jama Software’s REST and SOAP throttling features to ensure that your integration doesn’t introduce unnecessary load on your servers.


Importing large quantities of items can be taxing on the system. When importing relationships using the Import Relationships Plugin, we recommend importing these in batches of 250 to maintain performance. If you need to import many more relationships, consider using the REST API, for which we have a script available.

Recommended Actions

Work is ongoing to increase the system’s performance for more data, users, and complexity. We will continue to enhance our capabilities as our customers need change and data grow.

  • If you are managing high volumes of data in Jama Software, considering implementing an archiving strategy. Archiving projects in Jama Software will free up resources for active projects while still providing access to historical data.
  • If you are planning for more than 5,000,000 records or more than 150-225 concurrent users in Jama Software, you may want to consider using multiple instances.
  • Jama Software can synchronize data across multiple instances using the Jama Integrations Hub for situations where two teams must share requirements across instances.
  • The Jama Software Professional Services team can help you design a plan to organize your users and data across multiple instances.
Many of the performance issues noted above can be mitigated by process or procedures within the organization. Please consider the recommendations in this document or reach out to Jama Software for additional suggestions.

#administration #tutorial
1 comment


05-16-2017 13:23

Assuming we want to ensure that an on-premise Jama instance is within the engineering guidelines, can you provide some more details here as to how we confirm this?


  1. Are there any reports in Jama 2015.5 which provide these metrics? The "system health report" highlights individual projects which might be outside the per-project recommendations, but doesn't show per-instance summary numbers.

  2. If we have to derive these numbers ourselves, can it be queried via Velocity, or are direct database queries the only way?

  3. What qualifies as an "active record" or "active item" in Jama? Is this just items in the database DOCUMENT table with the ACTIVE column set to 'T', or do we need to account for records from other tables as well?