sql - jMeter "Prepared SELECT Statement" - バインド変数を代用しますか?

Question

「Prepared SELECT Statement」クエリタイプを使用して SELECT ステートメントを発行する JDBC リクエストを使用して、jMeter を使用して SAP HANA データベースの負荷テストを行っています。

select * from accounts where acc = '${__P(acct),)} order by ts LIMIT 10

数百億のレコードを含むテーブルから読み取りを行っており、1 秒あたり数千トランザクションのスループットが期待されます。「acct」は、CSV Data Set Config を使用して CSV から読み込まれた一意の PK であり、BeanShell Listener を使用して置換されます。

データベースキャッシュ内の SQL ステートメントには、次のようなステートメントが含まれています。

select * from accounts where acc = 110982 order by ts LIMIT 10

データベースは各ステートメントを解析する必要があり、CPU オーバーヘッドが高くなるため、これは問題です。「Prepared SELECT Statement」を使用すると、次のようなものが表示されると予想していました。

select * from accounts where acc = :acc order by ts LIMIT 10

ステートメントが準備され、実行時に値が置換され、再解析が回避される場所。

jMeter のドキュメントはこの件に関して無言なので、「Prepared SELECT ステートメント」の JDBC クエリタイプはバインド変数の代わりにリテラルを使用しますか?

score 1 · Accepted Answer

Prepared Select ステートメントは、apache Jmeter ドキュメントサイトから添付されたスクリーンショットに記載されているもののようになります。

準備された選択ステートメントを記述した方法が正しくありません。

また、CSV Data Set Config から変数を直接「${acct}」に渡すこともできます。プロパティ「__P(acct)」として渡す必要はありません。

以下の詳細を、準備された選択ステートメントの参照として使用してください。

select * from accounts where acc = ?  order by ts LIMIT 10

パラメーター値: ${acct}
パラメータータイプ: DB スキーマに従って

これが役立つことを願っています。

1 に答える 1