SE の雑記

SQL Server の情報をメインに Microsoft 製品の勉強内容を日々投稿

JMeter で SQL Server の負荷テスト (2018/08 版)

leave a comment

かなり前に書いた JMeter で SQL Server の負荷テスト のアップデートとして。

以前に書いた投稿は、2013 年のもので、5 年以上たっていますので、アップデートを交えながら、新たに確認した内容のメモを残しておこうかと。

環境構築インストール

本投稿を書いている 2018/9 時点の JMeter の最新は 4.0 となり、必要となるモジュールはこれらになります。

本投稿では、次の組み合わせで利用しています。

  • JRE : Java SE 10.0.2
  • JMeter : Version 4.0
  • SQL Server JDBC Driver : Version 7.0

JRE のインストール
投稿を書いている時点では「jre-10.0.2_windows-x64_bin.exe」を使ったのですが、前回の投稿と同様に、セットアップを実行すれば問題はありませんでした。
以前は、「C:\Windows 」配下に Java の EXE が配置されていたようですが、Java 10 では、「C:\Program Files (x86)\Common Files\Oracle\Java\javapath」が PATH に登録されるようでした。
JMeter のインストール
JMeter の場合は、インストールではなく、ダウンロードしたファイルの展開だけですね。
展開したディレクトリの「bin\jmeter.bat」を実行して、JMeter が起動すれば OK です。
image
SQL Server JDBC Driver のインストール
今回は、「sqljdbc_7.0.0.0_jpn.exe」を使っており、最初にこのファイルを実行して、ファイルの内容をディレクトリに展開します。
展開した中の「mssql-jdbc-7.0.0.jre10.jar」を JMeter の Lib ディレクトリに配置します。
「sqljdbc_auth.dll」については、「C:\Windows\System」にコピーしておきます。

 

SQL Server への接続テスト

環境構築が終わったら、接続のテストを実施してみます。
詳細については、JMeter のドキュメントの 6. Building a Database Test Plan を確認していただければ。
接続情報の追加
「Add」→「Config Element」→「JDBC Connection Configuration」を選択して、
image
接続の情報は次の画像のような内容となります。
image
上記の画像は、SQL Server 認証を使用したものとなります。
接続 URL には 接続 URL の構築 の内容を使います。
今回は次のような設定をしています。

  • Variable Name for created pool : 接続を一意に識別するための情報
    (クエリの設定をする際に、どの接続を使用するかで利用することになる)
  • Database URL : jdbc:sqlserver://<Server>;database=<Database>
  • JDBC Driver Class : com.microsoft.sqlserver.jdbc.SQLServerDriver
    (com.microsoft.jdbc.sqlserver.SQLServerDriver の方はうまく動かなったのでこの辺、注意した方がよいかも)
  • Username / Password : SQL Server 認証の設定

テストのスレッドの設定
接続の情報が設定できたら、テストを実施する際のスレッドの設定を行います。
「Add」→「Threads (Users)」→「setup Thread Group」をクリックして設定画面を表示します。
image
ひとまずテスト接続ですので、今回は初期設定で。
image
 
実行するクエリの設定
続いて、実行するクエリの設定を行います。
実行するクエリは、前工程で作成した「setUp Thread Group」に関連付けさせますので、作成した設定を選択した状態で、「Add」→「Sampler」→「JDBC Request」を選択します。
image
最初に「Variable Name of ~」でどの接続を使用するかを指定し、次に SQL Query に実行するクエリを指定します。
image
正常に実行されると、次のように SQL Server にクエリが実行されます。
image

パラメーターを使用したクエリの実行

パラメーター化クエリを使用したものでしたら、それほど難しくなかったので、実行するクエリの一部をパラメーター化したものの実行方法をまとめてみようかと。
6. Building a Database Test Plan の内容とほぼ同じかと。
クエリで使用するパラメーターの定義方法ですが、18.4 Configuration Elements の内容を元にすることになるのではないでしょうか。
基本形は次のものを抑えておけばよさそうです。

今回は、CSV を例として見てみたいと思います。
次のようなファイルを作成し、UTF-8 で保存しています。
日本語のテスト用として、「森?外る」という環境依存文字を設定しています。
image
JMeter では、これを呼び出すための「CSV Data Set Config」を設定します。
今回は次のような設定をしています。
JMeter の設定の基本的な事項となりそうなのですが、複数のフィールドを定義する際にはカンマ区切りで設定を行うのですが、カンマの後に空白を入れない方がよさそうです。
設定箇所によっては、見やすくするために入れた空白自体もデータとして認識してしまうことがありますので。
image
これで、CSV の内容を変数として利用することができるようになりましたので、次はクエリを設定してみます。
アドホックなクエリに対して、変数を埋め込む場合は、次のような設定を行います。
image
アドホックなクエリとして実行していますので、Query Type は「Select Statement」としています。
クエリ自体はパラメーターを埋め込んだ、単純なものですね。

SELECT '${C1}', '${C2}', ${C3}, ${C4}

 
今回は 4 スレッドで実行しているのですが、次のような実行が行われます。

クエリ内に CSV の内容が埋め込まれ、CSV には、3 レコードのみとなっていますので、4 スレッド目の実行には、1 行目のデータが使用されています。
image
これをパラメーター化クエリとして実行する場合には、次のような設定となります。
image
パラメーター化クエリとして実行するので、Query Typeは「Prepared Select Statement」を指定しています。
設定には以下を使用していますが、アドホックなクエリと異なり、パラメーターとして埋め込みますので、クエリには、プレースホルダとして ? を設定し、それに対応する値を「Parameter values」と「Parameter types」に指定しています。
Parameter types は、java.sql.Types の内容ということですので、その書式に従い指定します。

SELECT ?, ?, ?, ?
${C1},${C2},${C3},${C4}
NVARCHAR,NVARCHAR, INTEGER,INTEGER

最後のパラメーターの後ろが少し気になりますが、パラメーター化クエリとして実行されていますね。
image
この辺りを抑えておけると、クエリのテストの幅が広がるのではないでしょうか。

 

リモートサーバーを使用した複数台での実行

これが、今回動作を見ておきたかった内容なのですが、JMeter は複数台の環境を利用して、マスター / スレーブタイプで実行をすることができるようになっています。
これについてもチュートリアルが用意されています。

JMeter の実行環境を整えるため、JRE / JMeter / JDBC のインストールを実施した、別のサーバーを準備しています。
JMeter の複数サーバーの連動は、マスター / スレーブタイプとなります。

マスターには、先ほどまで使用していた環境をそのまま利用し、新たにセットアップした環境をスレーブとして利用することにします。
マスター / スレーブ共通
各環境間で使用されるポートですが、スレーブについては 1099 で要求を待ち受けるようです。

実行結果をマスターに戻す際の通信についてはハイポートが使用されるらしいですので、マスター / スレーブ間は、全通信を許可してしまった方が早いのかもしれないですね…。
今回は、検証環境のセグメント間については、すべての通信を許可してしまっています。
imageimage
スレーブの設定
本来はきちんと設定した方が良いと思いますが、今回はテストのため、スレーブの SSL を無効にしておきます。

スレーブの「bin\user.properties」を開き、「server.rmi.ssl.disable=false」 を「server.rmi.ssl.disable=true」に変更します。

(先頭に # がある場合は、外してコメント化を解除します)
設定の変更が終わったら、「bin\jmeter-server.bat」を実行して、マスターからの要求を受け付けられる状態としておきます。
正常に起動できると、次のように待ち受けされた状態となります。
image
パラメーター用の CSV ファイルを使用している場合は、各スレーブに配置しておく必要があるようでしたので、ファイルを配置する際のパスについては、全スレーブで共通にしておく必要があるのかと。

(マスターからパラメーターを読み込んで配布するという形ではないみたいですね)
マスターの設定

本来は、マスターも GUI を使わない方がよいらしいのですが、今回はグラフィカルに確認したいので、GUI を使っています。
マスター側も SSL を無効にするため「bin\jmeter.properties」(先ほどとファイル名は違います) を開き、「server.rmi.ssl.disable=true」の設定を実施しておきます。
JMeter の初期設定では、「Run」→「Remote Start」は「127.0.0.1」のみが設定されている状態となっています。
image
マスター側の設定として、テストで使用するスレーブを認識させる必要があります。

利用するスレーブの設定は、JMeter のディレクトリ内の「bin\jmeter.properties」に記述されています。
デフォルトでは、「remote_hosts」は「127.0.0.1」のみが登録された状態となっています。
image
ここにリモートで使用するサーバーを設定します。
image
「Run」の「Remote Start」に登録した IP が選択できるようになっていますね。

image
最初は、各サーバー単体にリモート要求を実施して、テストが実行されることを確認した方がよいかと。

マスターからスレーブに要求が遅れている場合、プロンプトに開始 / 終了のメッセージが表示されます。

image
SQL Server の場合は、トレースにホスト名を表示するようにすれば、どのサーバーからの要求かも確認できますので、まずは単体でリモートから要求が実行できていることを確認すると良いのではないでしょうか。
image
各サーバーで実行ができたら、「Run」→「Remote Start All」で全サーバーに要求を出します。

スレッドグループを 4 にした場合、次のような結果になりましたので、各サーバーで指定したスレッド数の実行が行われるようですね。

image
全サーバーでトータルの実行状況になりますが、サマリーレポートも確認できますね。
image
SQL Server に対してのテストは、この辺の情報が基本となりそうですね。
SQL Server をコンテナーとして実行することで、負荷テストに使用する検証用の SQL Server の環境構築の簡略化や、MicrosoftR Database Experimentation Assistant 2.6 で使用するためのワークロードを生成するために使用するなど、色々な仕組みが考えられそうです。

Share

Written by Masayuki.Ozawa

9月 1st, 2018 at 9:14 pm

Posted in SQL Server

Tagged with ,

Leave a Reply