その1のアップからだいぶ日が経ってしまい、いつの間にか年すら変わっていましたね。。。
” GAE負荷テスト その2 “では、動的なコンテンツを使用していない、静的なコンテンツだけの企業のWEBページをGAE上で運用した場合、無料で何PVまでアクセスできるか、弊社の旧トップページを使って試してみましょう。
| タイトル | |
| Part1 | GAE負荷テスト その1「Hello World!」 |
| Part2 | GAE負荷テスト その2「無料で何PVまで表示できるのか試してみた」（このページです） |
今回試した結果、
無料で12,000PV（1ページあたり、89KBの場合）
表示できました。
まず、前提として、GAEのBandwidth Outの無料枠は1GBまでです。
下記弊社旧トップページのサイズは89.184KBですので、1GBを1,048,576KBとしますと、理論値では「1,048,576KB / 89KB = 11,758PV」で無料枠を使い切ってしまうことになります。
また、弊社旧トップページのオブジェクト数は全部で13個ありますので、総リクエスト数の理論値は先ほど求めたPV数にオブジェクト数をかけ、「11,758PV × 13個 = 152,854リクエスト」となります。
このリクエスト数を超えたら、「Outgoing Bandwidth」のResourceを使いきってしまうと思われます。
※Outgoing Bandwidthはネットワークの回線容量についてのResourceになりますので、アクセスが増えれば増えただけ、Resourceを使用します。
以上のことを踏まえ、今回はテストパターンを２つ用意しました。
使用したツール : jakarta-jmeter-2.5.1
| パターン | 同時リクエスト数 | ループ数(PV) | オブジェクト数(html, css, jpg) | 総リクエスト数 | 無料リクエスト可能実行数 | アクセス可能PV数 |
| 1 | 1,000 | 12 | 13 | 156,000 | 156,000 | 12,000 |
| 2 | 1,500 | 12 | 13 | 234,000 | 156,311 | 12,023 |
※「無料リクエスト可能実行数」は、パターン1,2のリクエストで200番台を返してきた数です。数値は各パターンの「リクエスト数」と同じになっています。
弊社旧トップページ
ページサイズ:89KB
では、実際に検証パターンの詳細結果を見てみましょう。
パターン1 「1000スレッド／12ループ」 1回目
予想
理論値では、総リクエスト数は156,000ですので、リクエストの途中からエラーになるはずです。
懸念事項があるとすれば、同時リクエストの送信に私のPCが耐えられるかどうかですね。。。途中でOutOfMemoryErrorが出そうですが。。。
結果
全リクエスト完了時間 : 0.590秒
全リクエストのレスポンス平均時間 : 357msec
リクエスト完了結果 :
GAE管理コンソールDashboard
1秒かからずにOutOfMemoryErrorが出ました。。。
やはり私のPCでは耐えられませんでしたか。。。
GCEの設置とテスト前リソース状況
PCでは限界ですので、Google Compute Engine(略してGCE)にテスト環境を構築して、そこから負荷テストを行いたいと思います。
構築方法についてはまた日を改めて、紹介することにして、とりあえずはテスト環境のスペックだけ、載せたいと思います。
[テスト環境GCE]
少なくともメモリは8GBくらいは欲しいので、今回はこの「n1-standard-2」インスタンスを使用します。
OSは「CentOS」選べる中で最新バージョンを選択しました。
ここでは詳しくは書きませんので、他のインスタンス等については下記URLを参考にしてください。
https://developers.google.com/compute/docs/instances?hl=ja
[テスト前Resource]
パターン1, 2ともにFrontend Instance Hours とOutgoing Bandwidthのリソースは使用されていない状態から始めます。
パターン1 「1000スレッド／12ループ」 2回目
予想
理論値では、総リクエスト数は156,000ですので、リクエストの途中からエラーになるはずです。
結果
全リクエスト完了時間 : 1分18秒
全リクエストのレスポンス平均時間 : 12msec
リスエスト数 : 156000リクエスト
GAE管理コンソールDashboard
[テスト前Resource]
処理が完了したのはいいのですが、予想では「Outgoing Bandwidth」を使い切るはずなのに、0.92GBまでしか消費しませんでした。
んー、理論値よりも何からしらの余裕があるということなのしょうか？
「Frontend Instance Hours」のリソースは全く使用されていませんね。
前回の「Hello World」では少なからずリソースを消費しましたが、今回のテストでは静的ファイルのアクセスに消費するFrontend Instanceは0というお得な結果になりましたね。
jmeterのログ上は全て200が返ってきているのですが、GAE側のアクセスログは途中から200ではなく、204を返しています。
204？ 私はあまり見たことのないステータスコードね。ググってみますか。
204の意味は、「レスポンスのボディが無い」とのこと。
正直ピンと来ないですね。
旧トップページはちゃんと表示できますし。。。
200番台なので成功の部類なんでしょうが、正直気持ち悪いですね。
パターン2「1500スレッド／12ループ」
理論値152,854を超えてもリソースを使いきりませんでした。
1.00GBを使い切るために1,500スレッドに変えて実際の限界値を出してみましょう。
結果
リクエスト時間 : 2分43秒
リスエスト数 : 156,311リクエスト
GCE側でもOutOfMemoryErrorが出てしまいました。
jmeterに割り振った最大メモリは7300MBでしたが、これがリクエストの限界でした。
まとめ
パターン2の1500スレッド/12ループは消化不良な感じが否めませんが、パターン1の1,000スレッド/12ループで12,000PVのアクセスに耐えられたという結果には満足です。
1000スレッド/12ループで「Outgoing Bandwidth」リソースを使いきらず、さらに「Frontend Instance Hours」は消費0というのは驚異的な気がします。
それでは、次回は負荷テスト第三弾で「掲示板への書込と出力」を実施したいと思います。
| タイトル | |
| Part1 | GAE負荷テスト その1「Hello World!」 |
| Part2 | GAE負荷テスト その2「無料で何PVまで表示できるのか試してみた」（このページです） |