1. 概要
この記事は、TDV構成パラメーターである、セッション数、リクエスト数と、RDBデータソースのコネクションプールとの、消費の関連についてまとめたものです。
下図のように、クライアントアプリケーションからの接続やリクエストは、セッションやリクエストとして把握され、またそのリクエストによるデータのクエリは、データベースへのコネクションを使用します。
この記事では、いくつかのユースケースを例に、それらの消費の関連についてまとめています。
2. 各パラメーターの詳細
セッション数
JDBC/ODBC/ADO.NETクライアントからTDVサーバーへの接続数としてカウントされます。
同時接続できる最大数は、プルダウンメニュー「管理」→「構成...」の構成ダイアログで設定します。
- Client Drivers / Sessions / Maximum Sessions
リクエスト数
JDBC/ODBC/ADO.NETセッションから発せられるクエリーやリクエストの数としてカウントされます。
TDVサーバーが同時に処理できる最大数は、構成ダイアログで設定します。全セッションを通したトータルの数です。
- Client Drivers / Requests / Maximum Requests
コネクションプール（コネクション数）
RDBデータソースの設定において、TDVアダプタとRDBデータソース間の、コネクションプールで管理されるコネクション数です。
RDBデータソース共通の詳細プロパティとして、最大数、最小数を設定することができます。
- Connection Pool Maximum Size
- Connection Pool Minimum Size
3. ユースケース
ユースケース①：1セッション、1リクエスト/セッション
クライアント・アプリからのセッションが1つで、そのセッションからリクエストが1つ発せられるベーシックなケースです。
■ セッション数
クライアント・アプリ側から確立された接続の数だけセッション数が消費されますので、1つ消費されます。
■ リクエスト数
1つ消費されます。
■ コネクションプール（コネクション数）
データソース側のコネクションは、データソース①、②それぞれ1コネクションずつ消費されます。
ユースケース②：1セッション、2順次リクエスト/セッション
同じくクライアント・アプリからのセッションは1つですが、そのセッションからリクエストが2つ発せられるケースです。ただし、同時ではなく、1つ目のSQLリクエストのレスポンスを受けてから、2つ目のリクエストを発行するケースです。
■ セッション数
1つ消費されます。
■ リクエスト数
1つ消費されます。
リクエストは同時に発行されないため、消費されるのは1つです。
■ コネクションプール（コネクション数）
データソース側のコネクションも、データソース①、②それぞれ1コネクションずつ消費されます。
ユースケース③：1セッション、2同時リクエスト/セッション
反対に、1つのセッションから2つのリクエストが同時に発せられるケースです。同時とは、1つ目のレスポンスを受信するより前に、2つ目のリクエストを発するような状況です。
■ セッション数
1つ消費されます。
■ リクエスト数
2つのリクエストが同時に処理されている状態となりますので、リクエストは2つ消費されます。
■ コネクションプール（コネクション数）
データソース側のコネクションはリクエスト毎に消費されますので、データソース①、②それぞれリクエスト毎に1コネクションずつ消費され、計2ずつ消費します。
ユースケース④：2セッション、同時1リクエスト/セッション
2つのセッションから、それぞれ1つのリクエストが同時に発せられるケースです。
同時とは、別々に発せられたリクエストが、ほぼ同時か、又は1つ目のレスポンスが受信するより前に、2つ目のリクエストが発せられるようなタイミングの場合です。
■ セッション数
クライアント・アプリ側から確立された接続の数だけ、セッション数が消費されます。
2つのアプリから1接続ずつ確立していますので、2つ消費します。
■ リクエスト数
2つのリクエストが同時に処理されている状態となりますので、2つ消費されます。
リクエストは、セッション毎ではなく、全セッションを通したTDVサーバー全体の数としてカウントされます。
■ コネクションプール（コネクション数）
データソース側のコネクションはリクエスト毎に消費されますので、データソース①、②それぞれリクエスト毎に1コネクションずつ消費され、計2ずつ消費します。
ユースケース⑤：2セッション、順次1リクエスト/セッション
2つのセッションから、それぞれ1つのリクエストが発せられるケースです。
但し、このケースでは、別々に発せられるリクエストの、1つ目のレスポンスが受信された後に、2つ目のリクエストが発せられるような状況です。
■ セッション数
クライアント・アプリ側から確立された接続の数だけ、セッション数が消費されます。
2つのアプリから1接続ずつ確立していますので、2つ消費します。
■ リクエスト数
リクエスト数の消費は1つです。
1つ目のレスポンスを受信後、2つ目のリクエストを発するようなタイミングの場合、同時とはならないため1のままとなります。
■ コネクションプール（コネクション数）
1つ目のリクエストの後、2つ目のリクエストが処理されますので、データソース①、②それぞれ1コネクションずつ消費されます。
4. 使用状況の確認方法
セッション数、リクエスト数、コネクションプール数の使用状況は、それぞれ以下の画面で確認することができます。
セッション数
Studio Manager 画面
「Sessions」パネル で確認することができます。「Active Sessions」に現在アクティブなセッションの数が表示されます。但し、これにはStudio等からのセッション数も含まれます。
下例には、JDBCセッションが表示されています。
詳細につきましては、以下製品ガイドをご参照ください。
セッションパネル (tibco.com)
マネージャWeb
「モニタリング」→「セッション」 で確認することができます。「セッション」の「アクティブ」欄に、現在アクティブなセッションの数が表示されます。但し、これにはStudio等からのセッション数も含まれます。
また、各セッション行の詳細表示ボタンから、詳細を表示することもできます。
詳細につきましては、以下製品ガイドをご参照ください。
セッションページ (tibco.com)
リクエスト数
Studio Manager 画面
「Requests」パネル で確認することができます。
詳細につきましては、以下製品ガイドをご参照ください。
リクエストパネル (tibco.com)
マネージャWeb
「モニタリング」→「要求」 で確認することができます。
詳細につきましては、以下製品ガイドをご参照ください。
リクエストページ (tibco.com)
コネクションプール（コネクション数）
Studio Manager 画面
「Data Srouces」パネル で確認することができます。
対象のデータソース行、又はデータソースの詳細画面に、接続プールの状況が表示されます。
詳細につきましては、以下製品ガイドをご参照ください。
データソースパネル (tibco.com)
マネージャWeb
「モニタリング」→「データソース」 で確認することができます。
対象のデータソース行、又はデータソースの詳細画面に、接続プールの状況が表示されます。
詳細につきましては、以下製品ガイドをご参照ください。
データソースページ (tibco.com)