In general, Jira proactively caches a lot of data, thus many requests are served from the cache and do not require a database connection. How much data obtained from the cache vs Jira's database is going to vary greatly depending on the system- systems with high writes and low reads will use more DB connections than those with high reads and low writes for example.

While the below examples are provided using Splunk the same logic can be applied to any access log analysis application:

1. Determine maximum requests per minute from the load balancer logs

   (qualifier for access logs)  | bucket _time span=1m | stats count by _time | stats min(count) as min max(count) as max avg(count) as avg

   Note: The reason we do this for a minute and not for a second is because we accept that some queuing will occur. If we tune for the highest load second we will have many unused threads most of the time. If we tune for the highest load minute and average those requests out per second, we will see some queuing, but we will have the capacity to move those requests through quickly.

2. Determine average time to complete each request

   (qualifier for access logs) | chart avg(request_time) max(request_time)

3. Math time to determine maximum HTTP threads per node

   1. Determine maximum requests on average:

      Max requests per node = maxRequestsPerMinute / 60 / numberOfNodes, eg:
      8350 / 60 / 4 = 35

   2. Determine maximum number of HTTP threads required per second

      Number of http threads required per second = maxRequestsPerMinute * AvgTimeToCompleteEachRequest, eg:
      Maximum: 35 * 2.6 = 91

   3. Round up to allow for some future growth

      maxThreads = 100

4. DB connections for Jira can be much lower than the HTTP threads. Go for 25%:

   DB Connections = 100 * 0.25 = 25

5. Increase connections allowed on the database, with a buffer:

   Max connections on the db server = dbConnectionsPerNode * numberOfNodes + buffer ( arbitrary / debatable ), eg:
   25 * 4 + 20 = 120