GAE負荷テスト その2「無料で何PVまで表示できるのか試してみた」

その1のアップからだいぶ日が経ってしまい、いつの間にか年すら変わっていましたね。。。

” GAE負荷テスト その2 “では、動的なコンテンツを使用していない、静的なコンテンツだけの企業のWEBページをGAE上で運用した場合、無料で何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

※「無料リクエスト可能実行数」は、パターン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というのは驚異的な気がします。

それでは、次回は負荷テスト第三弾で「掲示板への書込と出力」を実施したいと思います。