通常、Jira は多くのデータを積極的にキャッシュしているため、多くのリクエストはキャッシュから提供され、データベース接続は必要ありません。キャッシュと Jira のデータベースからどの位のデータを取得するかは、システムによって大きく異なります。例えば、書き込みが多く読み込みが少ないシステムは、読み込みが多く書き込みが少ないシステムよりも多くの DB 接続を使用します。

以下は Splunk を使用した例ですが、どのようなアクセスログ解析アプリケーションにも同じロジックを適用可能です。

1. ロードバランサーのログから 1 分あたりの最大リクエスト数を特定します。

   (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

   注意: これを 1 秒間ではなく 1 分間で行うのは、ある程度のキューイングが発生することを受け入れるためです。最も負荷が高くなる秒に合わせて調整すると、ほとんどの時間で未使用のスレッドが多数存在することになります。最も負荷の高い分単位でチューニングし、1 秒あたりのリクエストを平均化すれば、多少のキューイングは発生しますが、リクエストを迅速に処理する容量は確保できます。

2. 各リクエストを完了するための平均時間を特定します。

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

3. ノードあたりの最大 HTTP スレッド数を特定するための計算を行います。

   1. 平均の最大リクエスト数を決定します。

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

   2. 1 秒間に必要な HTTP スレッドの最大数を特定します。

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

   3. 将来的な増加を見越して、切り上げます。

      maxThreads = 100

4. Jira の DB 接続数は、HTTP スレッドよりはかなり低くできます。25% を試します。

   DB Connections = 100 * 0.25 = 25

5. バッファを持たせて、データベースで許容する接続数を増やします。

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