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

Question

我有 android 客户端和 google app engine java 服务器。尽管我看到预热请求，但向我的端点发出的第一个请求(有时是 2-3 个请求)需要非常长的时间(8 - 20 秒甚至更长)。

这很烦人，因为另一个实例(我有 1 个常驻实例，我是唯一点击那里的用户，请求需要 100-200 毫秒，我每秒发送 1-3 个请求)可以在大约 500 毫秒内处理此请求，但它会生成新实例，发出预热请求并将请求发送到新实例(即使我设置了 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
有一些关于“使用自定义预热 servlet”的内容，但我仍然不知道如何预热端点...如果答案确实存在，请向我指出，准确地告诉我> 我该怎么办...

有人找到解决办法了吗？意思是，我希望我的新实例在启动端点后开始处理请求，因此它将在正常时间内处理来自真实用户的第一个传入请求，例如通常的 100 - 200 毫秒(或至少不到 1 秒)。我该怎么做？
请帮忙 ! :)

[编辑]

我的 web.xml (mb 它有帮助):

<?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 个空闲实例等待请求。当收到第一个请求时，它会发送它到了很久以前就被旋转起来并且闲置的那个实例等待，只是等待为某人服务。 “实例 1”(我们将这样调用它)愉快地返回回复 184 ms

• 您的第二个请求已在 22:05:58.121 收到(T + 12 约秒)

  (第二个请求也路由到唯一的服务实例 - 实例 1。它返回 182 ms 中的响应)

• 一旦 App Master(系统的管理部分)根据您的配置和请求负载进行扩展和实例)确定实例1不空闲，它发送预热请求到新实例(“实例 2”)，告诉它做好准备。

• 在 22:05:58.509 收到对实例 2 的预热请求 (T + 12 约秒)

• 根据需要完成多少工作来启动实例并准备好提供服务，收到此预热请求后将需要更短或更长的时间让实例 2 真正投入使用。事实上您已指定 <load-on-startup>1</load-on-startup>对于系统服务 Servlet 意味着它还将通过调用其 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应该“对应用程序的性能影响较小”...

<小时/>

这是您提供的日志向我们显示的所有信息。如果没有看到更多代码，我无法确定到底发生了什么(例如，根据您所包含的 jar 文件的数量，您的实例是否需要短时间或长时间来启动)，但这似乎是以下结果的结果您使用的功能的组合。也许第三个请求被放入待处理队列中，等待了 11 秒(高于 10 秒且低于 15 秒)，最后由任一实例提供服务(您是否在任一实例上看到了旋转请求，假设您定义了最多 1 个空闲实例？)，取剩余的 ~200 ms实际处理 API 调用，这与前两个请求的延迟一致。

我认为，如果您使用现有的设置，考虑到您现在可以看到请求负载对扩展的影响，您可能会发现这种延迟消失了。