For small-to-medium size Jira installations, no special tuning is typically required.

The following sections address optional Jira performance tunings that may be relevant to customers with larger installations.

Limiting Report Size

To block individual user reports from monopolizing system resources, Dataplane has a default limit of 75,000 Jira issues for the maximum number of Jira issues that may be included by an individual report. Reports returning more than this number of issues are prevented from running and instead display an error message to the user explaining the issue limit:

You may choose a different limit for the maximum number of issues allowed in report results by specifying the following JVM system property:

Property	Default Value	Value
com.arsenalesystems.dataplane.report.maxIssues	75000	<MAX_ISSUES>

For example, to increase this limit to 100,000 issues on a Linux system, add the following property setting to JVM_SUPPORT_RECOMMENDED_ARGS in the bin/setenv.sh file in your Jira installation directory:

-Dcom.arsenalesystems.dataplane.report.maxIssues=100000

See Atlassian's Jira documentation for directions on setting JVM properties on other systems.

Adjusting Available Database Connections

By default, Dataplane will use up to 8 concurrent database connections, or one third of the total Jira database connection pool, whichever value is larger. If you have not modified Atlassian's default Jira database configuration of 20 database connections, Dataplane will likely be using up to 8 connections.

This allows Dataplane to use enough connections to support multiple concurrent report requests, but this limit also prevents Dataplane from starving the core Jira application of database connections for other operations.

The defaults should be sufficient for most systems, but if you see slow-loading reports when many users are accessing the system, or if you see messages similar to the following in the Jira log, you may wish to increase your connection limit:

Request for new database connection is likely to exceed maximum limit of <NUMBER> connections

Use Jira's built-in database connection pool monitor to see how many active database connections are being used by Jira and Dataplane together.

Increasing the Jira Database Connection Pool Size

All of the database connections used by Dataplane are taken from the common Jira database connection pool.

To increase the number of database connections available to Jira, follow Atlassian's guide for tuning database connections.

A sufficient number of connections must also be made available in your database server configuration.

Adjusting Dataplane's Maximum Database Connection Usage

If you want Dataplane to use more or fewer than Dataplane's default, one-third fraction of the total Jira connection pool size, you may tune the number of database connections used by Dataplane. To do this, configure the following JVM system property in your bin/setenv.sh file, where <NUMBER> is the maximum number of database connections that Dataplane will attempt to use at a single time:

-Dcom.arsenalesystems.dataplane.db.maxConnections=<NUMBER>

All of Dataplane's database connections are taken from Jira's common JDBC connection pool, so the Jira connection pool size must be larger than the number you specify here.

Adjusting the Maximum Database Connection Wait Time

Once Dataplane has exceeded the maximum number of connections specified above, if a new connection is required, Dataplane will wait up to 60 seconds for an existing connection to become available. If no connections are made available during that time, Dataplane will abort the report and display an error message to the user.

The default value of 60 seconds should be acceptable for most environments. Should you have a need to tune the connection wait times, you can configure the following JVM parameter in bin/setenv.sh:

-Dcom.arsenalesystems.dataplane.db.maxConnectionWaitTime=<DELAY_IN_SECONDS>

Note that the specified value for maxConnectionWaitTime may not be smaller than 10 seconds.

Adjusting the Maximum Number of Threads Waiting for Database Connections

Dataplane also allows you to set an upper limit on the maximum number of threads that are permitted to wait for a database connection to become available. By default, up to 30 threads can be waiting for a database connection at any given time, which should be sufficient for most systems.

If more than the specified number of Dataplane threads are already waiting for a database connection, new requests for database connections will be immediately aborted without waiting and an error message will be shown to the user, which helps to prevent HTTP thread exhaustion.

To adjust the maximum number of threads that are permitted to wait for database connections, set the following JVM system property in bin/setenv.sh:

-Dcom.arsenalesystems.dataplane.db.maxWaitQueueLength=<MAX_THREADS>

By tuning this parameter, you can control the maximum number of HTTP threads that can be consumed by Dataplane-related tasks.

In general:

Maximum Dataplane HTTP Thread Usage = maxConnections (actively using database connections) + maxWaitQueueLength (each waiting up to maxConnectionWaitTime seconds for a connection)

For example, if you are using default Atlassian values for Jira database connection parameters and have not performed any of the above tuning, the maximum Dataplane HTTP thread usage will be 8 + 30 = 38 threads.

Page Contents

Browser not supported