JMeterでJSON形式のデータをPOSTリクエストで送信する方法
■はじめに
前回の記事（下記）でJMeterでGETリクエストの送信方法を紹介しました。
今回は続編で、JMeterからJSONのデータをPOSTリクエストで送信するときの設定を紹介します。
■実行環境
1. リクエストを受け付けるWebサーバの構築
Webサーバの構築は前回の記事を参照いただければと思います。
今回はJSONのデータをやり取りするので、app.jsにJSONのデータをやり取りするための記述と、index.jsにPOSTリクエストを受信できるように記述を追加します。
/* ~~~省略~~~ */ var bodyParser = require('body-parser'); app.use(bodyParser.urlencoded({extended: true})); app.use(bodyParser.json()); //*~~~省略~~~ */
コード1: app.jsに追記したコード
/* ~~~ 省略 ~~~ */ /* POST REQUEST */ router.post('/', function(req, res, next) { console.log(req.body); res.send('POST request'); }); /* ~~~ 省略 ~~~ */
コード2: index.jsに追記したコード
今回はデバッグのため、POSTリクエストで送られてきたデータをコンソールに表示するようにしました。
2. JMeterでJSONのデータを送信するPOSTリクエスト設定する
前回同様にまずはスレッドグループを作ります。JMeter左側のウィンドウにある「テスト計画」を右クリックし、 「追加」＞「Threads(Users)」>「スレッドグループ」を選択します。
次にリクエストを行うHTTPリクエストの設定をしていきます。 作成したスレッドグループの名前を右クリックし、「追加」>「サンプラー」>「HTTP リクエスト」を選択します。そうするとスレッドグループの下に「HTTPリクエスト」という設定が追加されます。
HTTPリクエストを選択し、下記図の赤枠の項目をそれぞれ設定します。今回はPOSTメソッドなので、メソッドを「POST」にし、送信するデータのエンコーディングも「Content encoding」で指定しています。送信するデータは下部にある、「Body Data」のなかに直接記載します。
- Webサーバ
- HTTPリクエスト
今回JMeterからサーバに対して、JSON形式でデータを送信するので、サーバ側でJSON形式と判定できるようにHTTPヘッダに、"Content-type: application/json"を追加します。
追加の方法は、スレッドグループの名前を右クリックし、「追加」>「設定エレメント」>「HTTP ヘッダマネージャ」を選択します。そうするとスレッドグループの下に「HTTPマネージャ」という設定が追加されます。
作成した「HTTPヘッダマネージャ」を選択し、下部にある「追加」ボタンを押下することで、ヘッダの設定を追加することができます。1度「追加」ボタンを押下し、名前に"Content-type"と入力し、値に"application/json"と記載します。これでHTTPヘッダの追加ができました。
ここまででPOSTメソッドでJSON形式を送信する設定が完了しました。結果をみるために、「結果を表で表示」を追加して、「開始」ボタンを押下してみます。
サーバ側のログを見ると、POSTリクエストが来ていることと送信されたデータを確認することができます。
また、「結果を表で表示」を見てみると、送信できていて成功していることがわかります。
■終わりに
近年のWebAPIは、JSON形式のデータをやり取りすることが多くなってきているのでこの記事が参考になればと思います。 今回はPOSTメソッドでJSON形式の定型データをサーバに送信していました。ただ、決まった値を複数回送信することは少ないと思うので、次回の記事ではCSVファイルにパラメータを記載し、そのCSVファイルのパラメータをJSONのデータに設定して送信する記事を作成したいと思います。
とりあえずJMeterを触ってみたい人向けの記事
■はじめに
夏バテ気味でけだるさなのなか働いているひよです。久々の投稿はJMeterにかかわるものとなります。
これからJMeterを使ってみたいという方向けに、JMeterのインストール、テスト環境の構築、そしてJMeterの実行まで簡単に記載します。勉強の手助けになれば幸いです。
■実行環境
1. JMeterのインストール
JMeterのインストールはいろいろな方が用意してくださっているので簡略化します。
まず、Apache JMeter - Download Apache JMeterから対象のプログラムをダウンロードします。
私は「apache-jmeter-5.1.1.zip」をダウンロードしました。
今回ダウンロードしたapache-jmeter-5.1.1はページに記載されている通りJava 8+が必要になるので、Javaをインストールしていない環境ではJavaをインストールしないと動かないので注意が必要です。
ダウンロードしたフォルダ内の、「\bin\ApacheJMeter.jar」をダブルクリックで起動して画面が起動できたらインストールは完了です。
2. テスト環境の準備
JMeterの使い方の試験のため公開されているURLへアクセスを試みるのは迷惑行為なので、ローカル環境にテスト環境を構築します。
以前作成した下記記事にもとづいて、nodeでwebサーバを用意します。nodeの環境は上述の実行環境のもので実施しています。
今回はテスト用に、GETを受け付けられるように準備します。 デフォルトのindex.jsを下記の通り変更します。
var express = require('express'); var router = express.Router(); /* GET REQUEST. */ router.get('/', function(req, res, next) { res.send('GET request'); }); module.exports = router;
3. JMeterの設定と実行
最後にJMeterの設定と実行をしてみます。
下記図のようにJMeter左側のウィンドウにある「テスト計画」を右クリックし、
「追加」＞「Threads(Users)」>「スレッドグループ」を選択します。
次にリクエストを行うHTTPリクエストの設定をしていきます。
作成したスレッドグループの名前を右クリックし、「追加」>「サンプラー」>「HTTP リクエスト」を選択します。そうするとスレッドグループの下に「HTTPリクエスト」という設定が追加されます。
HTTPリクエストを選択し、下記図の赤枠の項目をそれぞれ設定します。
ここで作成したHTTPリクエストをどの程度実行するかを設定します。
左側メニューのスレッドグループを選択し、スレッドプロパティを設定します。
各設定した内容で総テスト回数や1秒当たりのリクエスト数が決まります。
| 項目 | 計算式 |
|---|---|
| 総テスト回数 | スレッド数xループ回数 |
| 1秒あたりのリクエスト数 | 総テスト回数 / Ramp-UP期間(秒) |
※引用元はこちら
負荷ツールのスレッド数・Ramp-Up期間・ループ回数の関係 - Carpe Diem
今回は、スレッド数を10、Ramp-Up期間(秒)を10、ループ回数を10と試しに設定してみました。 この設定では、総テスト数が100回、1秒当たりのリクエスト数が10回となります。 ※今回は小さな値に設定していますが、大きな値にした場合、クライアントマシンの性能等により予定通り実行できないことがあるため注意が必要です。
ここまで設定できたら画面上部の開始ボタン（緑の三角）を押下し実行します。
実行するとWebサーバ側を見ていると次々に来ていることがわかります。
4. 実行結果をわかりやすく表示するために
3まででJMeterからWebサーバに対しアクセスを実行できたことは確認できました。 ただ、実行結果の解析がしづらいので、JMeterに実行した統計などの情報を記録する設定を行います。
画面左側のスレッドグループを右クリックし、「追加」>「リスナー」>「統計レポート」を選択します。この設定だけで実行した統計が見れるようになります。そのほかにも「結果を表で表示」などを設定するとわかりやすくなります。
統計レポートの設定が終わったので、再度開始ボタンを押下しJMeterからリクエストを出してみます。
すると、下記図のように結果がわかりやすく表示されました。
■おわりに
よく負荷試験を行ったりするときに登場するのがJMeterです。世間一般に浸透しているツールであるために、少しITかじっている人からは、簡単にできるでしょというイメージを持たれがちです。しっかり使い方を勉強し、どや顔してやりましょう。
SQL ServerのためのOS設定ベストプラクティス
■はじめに
SQL Serverを構築する際のベストプラクティスのサイトを見つけました。
英語だったので勉強がてらブログにまとめたいと思います。記事が書かれたのが2018年2月1日とのことで割と最近と思います。
■ベストプラクティス
ベストプラクティスは下記8つあるそうです。それぞれコメントしていきたいと思います。
- アロケーションユニットサイズの指定
- インスタントファイル初期化設定
- 電源プランの設定
- ウィルスソフトの除外対象設定
- Lock pages in memoryの設定
- ページファイルサイズの設定
- Windowsセキュリティポリシーの設定
- Windows 2012/2012 R2クラスタの動的クォーラム設定
1. アロケーションユニットサイズの指定
これはWindows Server 2008の時代から言われていることです。
ドライブをフォーマットするときにアロケーションユニットサイズの指定を行うことができます。SQL Serverは1つのページが8KBとなり、エクステントは8つのページファイルから成り立つので64KBの隣接した領域を利用します。そのため、アロケーションユニットサイズは64KBに設定することが推奨されています。
2. インスタントファイル初期化設定
これはWindows Server 2008の時代から言われていることです。
デフォルトではデータベースファイルやログファイルの操作（追加など）が発生した場合に、ゼロ埋めが発生するためオーバーヘッドがかかります。このゼロ埋めを行わないように設定を行います。設定方法は参考サイトを参照ください。
3. 電源プランの設定
これはWindows Server 2008の時代から言われていることです。
OSインストール時のデフォルトの電源プラン設定は「バランス」となっています。これを「高パフォーマンス」に変更を行います。この設定を行うことでバッチ処理のパフォーマンスが10%以上向上するといわれています。設定後にはCPUのクロック数が高い値で固定されることも確認できます。
4. ウィルスソフトの除外対象設定
これはWindows Server 2008の時代から言われていることです。
ウィルスソフトを常駐させる場合は、SQL Serverが利用するディレクトリおよびファイルを除外するように設定します。この設定を行うことでファイルのパフォーマンスが向上します。詳しい設定は下記リンクが役に立ちそうです。
https://support.microsoft.com/en-us/help/309422/choosing-antivirus-software-for-computers-that-run-sql-server
5. Lock pages in memoryの設定
これはWindows Server 2008の時代から言われていることです。
sys.dm_os_wait_statsなどで、バッファーラッチの待機イベントが多い場合にこの設定を行うことでパフォーマンスが向上することがあります。SQL Serverのサービス再起動が必要になるため、本番稼働中のマシンに対して実行する場合は計画的に実施する必要があります。
6.ページファイルサイズの設定
この項目については今まで意識をしたことがありませんでした。ページファイルの設定ガイドラインがあるのでそれに従いページファイルサイズを設定すると良いようです。下記リンクがガイドラインとなっており、最終更新日が2019年5月22日とのことで内容は信頼できそうです。 https://support.microsoft.com/en-us/help/2860880/how-to-determine-the-appropriate-page-file-size-for-64-bit-versions-of
7. Windowsセキュリティポリシーの設定
この項目については今まで意識をしたことがありませんでした。SQL Serverのサービスアカウントに必要な権限セットなどが記載されています。ポイントは当たり前のことですがSQL Serverの構成マネージャや、Windowsファイアーウォールを手動で設定しないと外部からアクセスできないということでしょうか。権限についての詳細を知りたい場合は下記ドキュメントが参考になります。 Configure Windows Service Accounts and Permissions - SQL Server | Microsoft Docs
8. Windows 2012/2012 R2クラスタの動的クォーラム設定
簡単に言うとWindows Server 2012以降のクラスターでは動的クォーラム構成が有効にしましょうとのことです。この設定を有効にすることで、クォーラム監視投票などが動的に調整されるようになるとのことです。
■終わりに
Windows Server 2008の時代から10年ほど経っていますが、新しいような内容がないことに驚きを感じました。コアな仕様は一度作りあがったらなかなか変更しないということでしょうか。
このベストプラクティスにはありませんでしたが、最近は物理サーバより仮想サーバが多くなってきたため、クラスタ構成の場合heartbeatの間隔なども適切に設定した方がよいのではと感じています。記事自体はSQL Serverのためのものなので、クラスタ構成の場合の設定は別で記事があるのかもしれません。
■参考
下記サイトが元です。
SQL Server 2017の可用性グループでデータベースバックアップを取得する際の備忘録
■はじめに
SQL Server 2017の3つのノードからなる可用性グループに対してデータベースのバックアップを試みました。メンテナンスプランのレポートログ上は成功したみたいなのですが、実際はバックアップファイルができながらなかったので四苦八苦しながら解消するまでの流れを記載します。原因なども推測の域をでていないため、今後いろんなパターンで検証してみたいと思います。
■取得できていなかった時の状況と対応策
筆者が作成したメンテナンスプランのモードは下記となります。
データベースのバックアップ（完全）
- ローカルサーバー接続のデータベースのバックアップ
- 種類：完全
- バックアップ先：ディスク
- バックアップの圧縮(Default)
データベースのバックアップ（トランザクション ログ）
- ローカルサーバ接続のデータベースのバックアップ
- 種類：トランザクションログ
- バックアップ先：ディスク
- バックアップの圧縮(Default)
また、可用性グループのバックアップ設定は下記のようにしていました。
- バックアップを行う場所：セカンダリ優先(S)
レプリカのバックアップ優先度(I)
| サーバインスタンス | バックアップ優先度(最小=1、最高=100) | レプリカの除外 |
|---|---|---|
| WIN2016N01 | 50 | |
| WIN2016N02 | 50 | |
| WIN2016N03 | 50 |
これで何度もバックアップを行っていましたが失敗しました。失敗していた原因はいくつか複合していました。
原因1: セカンダリレプリカでメンテナンスプランを実行していたこと
バックアップのテストを行う時にメンテナンスプランは、可用性グループのバックアップ設定で「セカンダリ優先(S)」としていたので、セカンダリレプリカでメンテナンスプランを実行していました。
何度実行してもメンテナンスプランのレポートは成功しているのに、バックアップファイルができないなと悩んでいました。ここでまず1つ誤りを犯していることがわかり、それは完全バックアップはセカンダリレプリカでは取得できないということでした。
そのため、プライマリレプリカでバックアップを行うようにしました。
原因2:バックアップを行う場所が「セカンダリ優先(S)」となっていこと
原因1でプライマリレプリカでバックアップを取得していましたが、やはり完全バックアップは取得できませんでした。理由については、バックアップを行う場所が「セカンダリ優先(S)」となっていることと、優先度の値がすべて均一になっていたからだと思います。
そこで、バックアップを行う場所を「プライマリ(R)」に変更したところバックアップを無事に取得することができました。
■終わりに
完全バックアップはプライマリじゃないと取れなさそうでしたが、差分バックアップならばセカンダリからとることができそうでした。もう少しパターンを網羅して検証をしてみたいと思います。
■参考
下記サイトが参考になりました。
SQL ServerのDBアカウントの権限管理を考える
■はじめに
SQL Severのアカウントを作成するときに、適切なアカウント管理をしたいと改めて権限管理について考えてみました。システム監査が行われるような企業では、必ずアカウント管理は問われる部分ですのでしっかりしていきたいものです。
本記事の想定環境
・MW: SQL Server 2017
■現状と課題
SQL Serverのアカウントは大きく、インスタンス範囲で権限を与える「サーバレベルのロール」と、データベース事に権限を管理する「データベースレベルのロール」の2種類があります。大きくサーバレベルのロールで一定の権限を制御し、データベースレベルのロールで複数あるデータベースについて細かく権限を制御する思想と読み取れます。
ただし、データベースレベルのロールは細かく権限が管理されていることから、1インスタンス上に複数のデータベースが作成されるような設計のサーバを運用する場合、規模にもよりますが下記2つの負担がどのシステム運用担当へかかるのかと思います。
- アカウント管理にかかわるサービス要求数が多いこと
- ユーザごとに細かい権限のリクエストがあり、一つずつ設定するのは手間がかかること
これらの負担に対しデフォルトの権限で管理している場合は、大体のユーザに必要以上のsys_admin権限や、db_owner権限を付与してしまいがちです。（やっちゃいけませんが）
強い権限があるとユーザはなんでもできてしまうので、オペレーションミスや悪意を持ったユーザにアカウントを乗っ取られたときのリスクは大きいです。そのため、最小権限でかつ簡易に管理できる解決策はないものかと考えていました。
■解決策
安直に考えた解決案は下記2つです。
1. アカウント管理システムを導入する
きめ細かいアカウント管理を行えるシステムを導入する。
アカウント管理システムを導入することで、申請書に基づいて自動でアカウント管理をしてくれることと、細かい権限が選択できることで上記2つの課題を解決することができると考えました。
ただし内製の場合、SQL Serverのエディション事に権限と機能が異なることと、これからの新バージョンが出来上がるたびにメンテナンスを行わないといけません。そのため、規模に応じて外部ソフトウェアを購入を検討してもいいかもしれません。
また、大きな会社だと会社としての内製のアカウント管理システムがあり、それが希望するDB製品に対応しておらず対応予定もないという悲しい結末に当たるかもしれません…
2. アカウントのロールを作成する
SQL Serverは「サーバレベルのロール」および「データベースレベルのロール」を作成することができます。
どのようなロールがあり、どのような権限があるとどのようなコマンドなどが実行できるかは、下記ポスターに一覧化されているので見ていただけるとわかりやすいかと思います。
aka.ms ※ダウンロードしておくのおすすめです。
どちらを作成するべきか？は組織の規模と、データベースの管理思想によって異なるためどちらがいいかは一概に言えません。個人的な意見としては、複数のインスタンスをまとめて管理しているときに、各インスタンス内のデータベース事に「データベースレベルのロール」を作成するのは面倒と感じてしまいます。そのため、アカウント発行先のチームごとに、「サーバレベルのロール」で大枠の権限を付与し、それでも制御できないかゆいところを「データベースレベルのロール」で補完する設計が管理上も楽になるのではないかと考えています。
■結論
会社の規模等により状況は異なりますが、個人的にはシステムで管理するのが一番楽と考えています。しかし、予算などの理由から難しい場合はロールで管理するで十分と考えています。ただし、ロールを作成して運用していたのち、システムを導入するとなった場合、独自のロールをインポートできるかどうか、インポートできない場合はどうするかは要件定義の時にしっかりと検討していただきたい点です。
■終わりに
アカウント管理はシステム運用開始してから、システム運用終了までずっと付きまとう業務です。この業務をどこまで楽にできるようにしておくかで、システム運用後のランニングコストに響いてきますので、導入時に検討していただく価値はあると思っています。
SQL Serverは「アプリケーションロール」というロールもあるようです。ただ、今までずっとSQL Serverの面倒を見てきましたが、「アプリケーションロール」を設定したいというサービス要求などは全くありませんでした。この機能をうまく使うベストプラクティスは謎です。ただ、このロールを使わなくても「サーバレベルのロール」および「データベースレベルのロール」で十分なため深く考えないようにします。詳しい方でこんな時に使うと便利だよなど知見があれば教えていただきたいです。
■参考
毎度ながらマイクロソフト様のドキュメントを参考にしています。
番組表アプリの作成を検討した結果：没
今日は番組表みたいなカレンダーアプリがあったら便利なのではないか？ということで草案をぱっと考えていましたが、あまり効果がでなさそうだったのでその没案をまとまりなくグダグダと書き連ねたいと思います。
■はじめに（動機）
日本にはN〇Kや民放が多く存在します。そして各放送局それぞれが番組表を持っています。
またそれだけではなく最近はWebの番組も増えてきており、Youtubeやニコニコ生放送などの番組も充実しています。
そのため、新聞に記載されているテレビ番組表だけでは足りないのではないか？というのがきっかけです。
■必要な機能について
個人的にあったらいいのではないかと検討した機能は下記となります。
自分の好きな番組をかき集めたマイカレンダー機能
番組を登録してカレンダーに反映するし表示する機能リマインダー機能
時間になったらpush通知してくれる機能
これぐらいシンプルでも十分じゃないかと思いました。
■実現方法について
好きな番組の情報（番組名、日時）をカレンダーに登録し、日時が近くなったらpush通知するだけです。
ただ、工夫が必要だと思った点は、カレンダーの登録機能です。ユーザが手入力ですべて入れるのはとても面倒です。そのため、下記機能も必要かなと追加で考えました。
- 番組表を見れて好きな番組を選択するだけにする
この機能の実現には、各放送局のテレビ番組表をスクレイピングして作成する。もしくは、すでにテレビ番組表のデータを配信しているAPIを探してそれを呼び出すなどの選択肢があります。スクレイピングするにしても100局以上のサイトを個別に解析してメンテナンスするのは大変そうです…
■没にした理由は下記3つです。
・家電への連携機能の検討が必要
今の時代はレコーダーなどが優秀なので、気になったテレビ番組は簡単に録画して後から見れるようになりました。
そのため、それらの家電への連携機能がないと実用性が少ないのではないかと感じました。
・Webの番組を選択する方法の難しさ
これが課題にぶち当たりました。youtubeなどではチャンネル登録しておけばその情報が手に入ります。ただ、チャンネル登録していないと何も情報が入りません。そのうえ放送されるコンテンツの数に制限はありません。そのため手で入力せざるを得ないのではないかと思った次第です。
・Googleカレンダーがすでに優秀
これ専用のアプリを作るまでもなく、Googleカレンダーがとても優秀なことです。メールしたらカレンダーに反映したり、リマインダー機能があるのでこんなアプリを作らずとも困ることはない点です。そのあたりは差別化がとても難しいです。
■おわりに（結論）
単純なアプリもなかなか作ろうと思ったときに費用対効果を考えると手がでなくなってしまいました。
最近知ったのですが、私は東京にずっといるのでテレビ番組のチャンネルはたくさんあるもんだと思っていました。ただ、都道府県によっては民放が数局しかないところもあるそうです。そういった地域の方々がWeb番組などをたくさんみているんでしょうか。見逃し配信サイトとかで見ている人達の都道府県のデータを取ったら何か面白いことできそうです。
また、最近は見逃した番組もあとからインターネットで簡単に見れる時代になりました。そんな中でリアルタイムで見たいテレビ番組って何があるだろうか？って考えたときに思いつくのは、音楽のライブ、スポーツなどかと思いました。どちらも共通するのは生中継であることがポイントで、どうなるかわからない結果を共有しながら楽しむところにリアルタイムでみたいと感じるポイントがあるのかなと個人的に思いました。
SQL Server 2017で可用性グループにDBを追加する際の備忘録
可用性グループの構築の仕方がなしにいきなりDBを追加する際の備忘録となってしまいました。おいおい可用性グループの構築の仕方も作成したいと思います。
■はじめに
Microsoft様のサイトに事前チェックリストがあるのでそれを見ればいいのですが、可用性グループに追加するときに躓いた点がありましたので忘れずに記録しておきます。
■既存の可用性グループにDBを追加する際の備忘録
とりあえず下記が大事です。
- 追加するデータベースのログレベルは「完全」となっていること
- 追加するデータベースの完全バックアップを取得していること
- 可用性グループを構成するノードすべてが正常な状態であること
- セカンダリレプリカのDBでは「RESTORE WITH NORECOVERY」でバックアップファイルからDBを復元し、
「可用性グループへの結合」を選択する。
ここまで終わってやっと可用性グループに追加でき状態が同期済みになりました。慣れるまで少し大変そうです。
■おわりに
運用時の制限はかかってしまうけれど、それ以上の効果があると期待しているので可用性グループを触って覚えるは継続していきたいと思います。記事の内容に誤りなどありましたら、コメントで教えて頂けると助かります。
■参考
下記ページに記載がありました。 *
可用性グループの前提条件、制限事項、推奨事項 - SQL Server Always On | Microsoft Docs
