Question

我有Android客户端和谷歌应用程序引擎java服务器。即使我看到热身请求，我的端点的第一次请求（或有时2-3次请求）需要非常长的时间（8 - 20秒甚至更长）。

这很烦人，因为另一个实例（我有1个常驻实例，我是唯一一个点击那里的用户，请求需要100-200ms，我每秒发送1-3个请求）可以在〜中提供这个请求500ms，但它生成新实例，发出预热请求并将请求发送到新实例（即使我设置min_pending_latency = 10000）。例如：

I 2014-12-09 18:39:51.438 200 0 B 3657ms /_ah/warmup
I 2014-12-09 18:39:55.649 200 7.7 KB 8673ms /_ah/spi/com.sth.MyEndpoint.getMyEntity
I 2014-12-09 18:40:15.349 200 7.7 KB 9081ms /_ah/spi/com.sth.MyEndpoint.getMyEntity
I 2014-12-09 18:43:17.328 200 7.7 KB 135ms /_ah/spi/com.sth.MyEndpoint.getMyEntity

我不希望我的用户在几十秒内随机延迟。我看了这页：
https://cloud.google.com/appengine/docs/java/config/appconfig#Java_appengine_web_xml_Warmup_requests
有一些关于＆＃34;使用自定义预热servlet＆＃34;但是我仍然不知道如何对端点进行预热......如果答案确实存在，请指出我，告诉我完全我应该做什么... < / p>

这里有人找到了解决方案吗？这意味着，我希望我的新实例在启动端点后开始处理请求，因此它将在正常时间内首先向真实用户发出请求，例如通常的100 - 200毫秒（或至少不到1秒）。我该怎么做？
请帮忙！：）

[编辑]

我的web.xml（有帮助）：

<?xml version="1.0" encoding="utf-8" standalone="no"?><web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="2.5" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

<servlet>
<servlet-name>SystemServiceServlet</servlet-name>
<servlet-class>com.google.api.server.spi.SystemServiceServlet</servlet-class>
<load-on-startup>1</load-on-startup>
<init-param>
 <param-name>services</param-name>
 <param-value>com.sth.MyEndpoint</param-value>
</init-param>
</servlet>
<servlet-mapping>  
<servlet-name>SystemServiceServlet</servlet-name>
<url-pattern>/_ah/spi/*</url-pattern>
</servlet-mapping>
</web-app>

[编辑] 还有我的appengine-web.xml：

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
<application>myappname</application>
<version>version4</version>
<threadsafe>true</threadsafe>
<precompilation-enabled>true</precompilation-enabled>
<!-- Configure java.util.logging -->
<system-properties>
    <property name="java.util.logging.config.file" value="WEB-INF/logging.properties" />
</system-properties>
<automatic-scaling>
    <min-idle-instances>1</min-idle-instances>
    <max-idle-instances>1</max-idle-instances>
    <min-pending-latency>10.0s</min-pending-latency>
    <max-pending-latency>15.0s</max-pending-latency>
</automatic-scaling>
<warmup-requests-enabled>true</warmup-requests-enabled>
</appengine-web-app>

Answer 1

我会在这些请求发生时写出系统上发生的事件的详细跟踪，我希望它能解决问题所在。请注意，请求日志上的时间戳告诉您何时从应用程序发送请求响应，因此我将参考收到请求的时间在应用程序中减去它们的运行时间（日志行的ms字段）

您的第一个请求已在22:05:46.717收到（我们将此T + 0秒调用）
您已将min_idle_instances设置为1并且max_idle_instances也已设置到1，所以在任何给定时间系统只能有1个空闲实例等待请求。收到第一个请求后，它会发送它是很久以前旋转的那个实例，而且是空闲的等待，等着为某人服务。＆＃34;实例1＆＃34; （正如我们所说的那样）愉快地回归 184 ms
您的第二个请求是在22:05:58.121（约T + 12秒）收到的

（第二个请求也被路由到唯一的服务实例 - 实例1.它返回182 ms中的响应）
App Master（管理系统的一部分）根据您的配置和请求加载进行扩展和实例）确定实例1不空闲，它发送预热请求到新实例（＆＃34;实例2＆＃34;）告诉它做好准备。
在22:05:58.509（T + 12秒左右）收到对实例2的预热请求
根据需要完成多少工作来启动您的实例并准备好投放服务，收到此预热请求后需要更短或更长的时间实例2实际上正在服务。您为系统服务servlet指定了<load-on-startup>1</load-on-startup>这一事实意味着它还将通过调用其init方法来加载Endpoints SystemServiceServlet。这将进一步增加实例服务之前的时间。

（请注意，预热请求需要4.129秒才能响应）

第三次请求是在22:06:10.838（约T + 24秒）收到的

（请注意，在实例2收到预热请求后大约12秒或预热请求实际响应后大约8秒（即实例2启动时）接收到此请求。

您已定义minimum_pending_latency = 10.0s这一事实通常意味着当收到应用程序主机确定没有准备好提供的免费实例的请求时，请求将等待最小值 10.0s（根据您的最大值，15.0s的最大）。您已定义minimum_idle_instances，according to the docs这一事实意味着minimum_pending_latency对您的应用的影响应该会减少{＆1;}。性能＆＃34; ...

这是您提供的日志向我们显示的所有信息。我无法确定没有看到更多代码究竟发生了什么（例如，根据您所包含的jar文件的数量，您的实例是否会花费很短或很长时间来启动），但它似乎是您使用的功能组合的结果。也许第三个请求被放入待处理队列中，等待11秒（10以上且低于15），最后得到任一个实例服务（你是否看到任何一个实例的降速请求，假设你定义了1-idle-instance max？），使剩余的~200 ms实际处理API调用，这与前两个请求的延迟一致。

我认为如果您使用自己的设置，考虑到您现在可以看到请求加载对扩展的影响，您可能会看到此延迟消失。

应用程序引擎预热请求不适用于端点

1 个答案: