低负载下应用引擎一致的延迟峰值

时间:2016-10-21 14:33:47

标签: java google-app-engine google-cloud-endpoints objectify

我注意到我在应用引擎上运行的应用程序会出现周期性但持续的延迟峰值。起初我认为网络可能很慢,但应用统计数据证实并非如此。

我已经能够使用较新版本和较新版本的SDK重现延迟峰值,目前我正在使用以下内容:

  • App引擎SDK:1.9.42
  • Google云端点:1.9.42
  • Objectify:5.1.13
  • Appstats(调试网络延迟)

因此在应用程序上的使用率相当低,在过去的30天里我通常不到0.04次请求:

requests per second

大部分工作也是通过一个实例完成的: enter image description here

大多数操作的延迟都在一秒之内,但是令人震惊的请求数量要长10到30倍。

Latency density distribution

5% of requests take 23 seconds or longer...

所以我认为它必须只是网络延迟,但每个缓慢操作的appstat都会反驳这一点。数据存储和网络始终非常可靠。这是一个缓慢请求的解剖结构,耗时超过30秒:

app stats of operation taking 31 seconds

以下是正常请求的解剖: enter image description here

在高级别,我的代码非常无趣:它是一个简单的api,可以进行一些网络调用,并从云数据存储区保存/读取数据。整个来源可以在github here找到。该应用程序在单个自动扩展应用程序引擎实例上运行并且已预热。

上个月的CPU使用情况似乎没有显示任何令人兴奋的事情: enter image description here

很奇怪,即使是快速操作,也会花费大量的时间在CPU上,即使代码只是创建了一些对象,它们仍然存在并返回JSON。我想知道CPU是否被另一个应用程序挂在我的应用程序引擎实例上,这可能会导致性能周期性降低。

我的appengine.xml配置如下所示:

<?xml version="1.0" encoding="utf-8"?>
<appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
    <application>sauce-sync</application>
    <version>1</version>
    <threadsafe>true</threadsafe>
    <automatic-scaling>
        <!-- always keep an instance up in order to keep startup time low-->
        <min-idle-instances>1</min-idle-instances>
    </automatic-scaling>
</appengine-web-app>

我的web.xml看起来像这样:

<web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">
    <servlet>
        <servlet-name>SystemServiceServlet</servlet-name>
        <servlet-class>com.google.api.server.spi.SystemServiceServlet</servlet-class>
        <init-param>
            <param-name>services</param-name>
            <param-value>com.sauce.sync.SauceSyncEndpoint</param-value>
        </init-param>
    </servlet>
    <servlet-mapping>
        <servlet-name>SystemServiceServlet</servlet-name>
        <url-pattern>/_ah/spi/*</url-pattern>
    </servlet-mapping>

    <!--reaper-->
    <servlet>
        <servlet-name>reapercron</servlet-name>
        <servlet-class>com.sauce.sync.reaper.ReaperCronServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>reapercron</servlet-name>
        <url-pattern>/reapercron</url-pattern>
    </servlet-mapping>

    <servlet>
        <servlet-name>reaper</servlet-name>
        <servlet-class>com.sauce.sync.reaper.ReaperServlet</servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>reaper</servlet-name>
        <url-pattern>/reaper</url-pattern>
    </servlet-mapping>


    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
    </welcome-file-list>

    <filter>
        <filter-name>ObjectifyFilter</filter-name>
        <filter-class>com.googlecode.objectify.ObjectifyFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>ObjectifyFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
</web-app>

TLDR我完全陷入困境,我不确定如何调试或解决这个问题,我开始认为这对应用引擎上的小型应用程序来说是正常的。

我正在考虑关闭驻留实例一段时间,希望我的应用程序刚刚运行了一些下铺硬件,或者旁边一个消耗大量资源的应用程序。有没有人遇到类似的性能问题或知道其他方式来分析您的应用程序?

编辑:

我尝试在1个驻留实例上运行,我也尝试在2-4 per this question设置并发请求而没有结果。日志和应用程序都确认等待我的代码最初运行花费了过多的时间。这是一个请求,在我的第一行代码运行之前需要25秒,不确定此时端点/应用程序引擎正在做什么。

25 seconds before my code is run

再次加载仍然很低,这是请求在一个预热的实例上。

编辑2:

似乎无论出于何种原因,应用引擎+端点都无法与min-idle-instances设置良好匹配。恢复默认的应用引擎配置修复了我的问题。

enter image description here

1 个答案:

答案 0 :(得分:3)

我没有答案,但我可以为您提供一些调试技巧。

Appstats可能会也可能没有正确报告。但是,日志消息会加上时间戳。记录之前&amp;在每次RPC操作之后。这应该会给你一些见解。

30秒的延迟听起来很像预热请求,应该在日志中清楚标明。我过去发现的一件事是,为低流量应用设置任何常驻实例(不直观)往往会将大量请求路由到冷实例。使用默认设置并设置cron任务以每分钟ping一次端点。