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

ご注意

この記事は 2014年3月25日 に書かれたものです。内容が古い可能性がありますのでご注意ください。

その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を使用します。 以上のことを踏まえ、今回はテストパターンを2つ用意しました。 使用したツール : 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まで表示できるのか試してみた」(このページです)

Google のクラウドサービスについてもっと詳しく知りたい、直接話が聞いてみたいという方のために、クラウドエースでは無料相談会を実施しております。お申し込みは下記ボタンより承っておりますので、この機会にぜひ弊社をご利用いただければと思います。

無料相談会のお申込みはこちら