AppEngine响应时间差异

我正在考虑使用AppEngine来部署我正在开发的webapp。 作为我对AppEngine平台的调查的一部分，我一直在检查简单请求的响应时间。 为此，我编写了一个简单的PING servlet：

@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程序，每秒向该servlet发出一个请求，并计算完成请求所需的时间。 获取页面内容使用以下代码。

 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需要不到500ms的所有请求，所有请求需要超过500ms才能完成failreqs是在下载过程中抛出IOexception或者收到的内容不等于“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到1177毫秒之间完成。

这与在Amazon EC2上运行的微实例上针对相同servlet运行的同一时段的以下输出进行比较。

 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实例正在“美国东部”运行。 我不知道Google在哪里运行我的AppEngine实例。

我可以做任何事情来提高AppEngine响应时间的一致性，还是我认为AppEngine的正常变化？

Answer 1

您看到的“迟到”请求是由于App Engine启动了新的Java运行时来处理您的请求。 App Engine会根据需要增加应用程序运行的实例数，并在一段时间不活动后调低空闲实例。

对于低流量应用程序，此行为更加明显，因为即使是单个用户也可能导致需要新运行时间的峰值，并且实例更可能因不活动而关闭。 随着应用流量的增加，您看到的预热请求数量将与流量成比例下降。

Answer 2

据我所知，差异只是谷歌正在使用的网络属性。