2010-11-25 24 views
8

開発中のWebアプリケーションの展開にAppEngineを使用することを検討しています。 AppEngineプラットフォームの調査の一環として、私は単純な要求に対する応答時間を確認しています。このため、私はシンプルなPINGサーブレット書かれています:AppEngine応答時間差

@SuppressWarnings("serial") 
public class Ping extends HttpServlet 
{ 
    @Override 
    public void doGet(@SuppressWarnings("unused") HttpServletRequest xiReq, 
        HttpServletResponse xiResp) 
        throws IOException 
    { 
    xiResp.setContentType("text/plain"); 
    xiResp.getWriter().println("PONG"); 
    } 
} 

を私はそれが要求を完了するのにかかった時間、このサーブレットや時間に毎秒要求を行うためのJavaプログラムを書かれています。ページコンテンツを取得するには、次のコードを使用します。

private static String getPageContent(String url) throws IOException { 
    String result = null; 
    URL reqURL = new URL(url); 
    URLConnection connection = reqURL.openConnection(); 
    connection.setConnectTimeout(30 * 1000); 
    connection.setReadTimeout(30 * 3000); 
    InputStream webStream = connection.getInputStream(); 
    BufferedReader reader = new BufferedReader(new InputStreamReader(webStream)); 
    result = reader.readLine(); 
    reader.close(); 
    return result; 
} 

3分ごとに私のモニタスクリプトは、次の形式でデータを出力します

date,num_reqs,num_failedreqs,avg_reqtime,num_normreqs,avg_normreqtime,num_latereqs,avg_latereqtime 

normrequestsを latereqsを完了するために、以下の500ミリ秒を取るすべての要求が完了するまでに500msのより長い時間がかかるすべての要求されています failreqsはダウンロード中にIO例外をスローするか、または受信したコンテンツが "PONG"と等しくない場合

最後の20分間の出力は次のとおりです。

Thu Nov 25 10:04:01 GMT 2010,300,0,186,295,171,5,1093 
Thu Nov 25 10:09:28 GMT 2010,300,0,191,292,173,8,842 
Thu Nov 25 10:14:52 GMT 2010,300,0,184,295,167,5,1177 
Thu Nov 25 10:20:15 GMT 2010,300,0,182,294,168,6,876 
Thu Nov 25 10:25:46 GMT 2010,300,0,172,298,167,2,827 

これは、5分ごとに2~8回の「遅延」要求が平均827~1177msの間に完了することを示しています。

これは、Amazon EC2上で動作するマイクロインスタンス上の同じサーブレットに対して実行された同じ期間の次の出力と比較しています。

Thu Nov 25 10:03:53 GMT 2010,300,0,177,300,177,0,0 
Thu Nov 25 10:09:20 GMT 2010,300,0,179,299,178,1,583 
Thu Nov 25 10:14:43 GMT 2010,300,0,176,299,175,1,545 
Thu Nov 25 10:20:07 GMT 2010,300,0,176,299,175,1,531 
Thu Nov 25 10:25:37 GMT 2010,300,0,181,298,178,2,669 

これは「遅延」要求がはるかに少なく、これらの低速要求の応答時間がはるかに小さいことを示しています。

私はイギリスに拠点を置くサーバーからリクエストしています。私のAmazon EC2インスタンスは "US East"で動作しています。 GoogleがどこのAppEngineインスタンスを実行しているのか分かりません。

AppEngineの応答時間の一貫性を向上させるために何かを行うことができますか、それともAppEngineで通常見ている分散ですか?

答えて

0

私が知る限り、分散はGoogleが使用しているネットワークの単なるプロパティです。

3

「遅れた」リクエストは、App Engineがリクエストを処理するための新しいJavaランタイムをスピンアップするためです。 App Engineは、必要に応じて実行しているアプリのインスタンスの数を増やし、何も操作しないとアイドル状態のインスタンスを停止させます。

個々のユーザーでも新しいランタイムのスピンアップが必要なスパイクが発生し、非アクティブのためにインスタンスがシャットダウンされる可能性があるため、この動作はトラフィックの少ないアプリケーションでははるかに目に見えます。アプリへのトラフィックが増加するのに応じて、表示されるウォームアップリクエストの数はトラフィックに比例して減少します。

+0

これは、アプリケーションログに新しいインスタンスが開始されていないため、表示されません。私は1秒間リクエストをアプリケーションに送りますが、これは1つのインスタンスを常に実行し続けるのに十分です。 – mchr

+1

ログに_any_インスタンスが起動していないと表示されますか? App Engineは、短期間のトラフィック急増を処理するために、かなり低いトラフィックに対しても複数のインスタンスを実行します。 –

+0

私は一定の1リクエスト/秒の読み込みを行うスクリプトを実行していました。 AppEngineは、スクリプトを開始するとログを表示し、負荷を処理するためにインスタンスが開始されます。この1つのインスタンスは、私の1リクエスト/秒を簡単に処理します。スクリプトの実行中にそれ以上のインスタンスは開始されません。 – mchr