我注意到我在应用引擎上运行的应用程序会出现周期性但持续的延迟峰值。起初我认为网络可能很慢,但应用统计数据证实并非如此。
我已经能够使用较新版本和较新版本的SDK重现延迟峰值,目前我正在使用以下内容:
因此在应用程序上的使用率相当低,在过去的30天里我通常不到0.04次请求:
大多数操作的延迟都在一秒之内,但是令人震惊的请求数量要长10到30倍。
所以我认为它必须只是网络延迟,但每个缓慢操作的appstat都会反驳这一点。数据存储和网络始终非常可靠。这是一个缓慢请求的解剖结构,耗时超过30秒:
在高级别,我的代码非常无趣:它是一个简单的api,可以进行一些网络调用,并从云数据存储区保存/读取数据。整个来源可以在github 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秒,不确定此时端点/应用程序引擎正在做什么。
再次加载仍然很低,这是请求在一个预热的实例上。
编辑2:
似乎无论出于何种原因,应用引擎+端点都无法与min-idle-instances
设置良好匹配。恢复默认的应用引擎配置修复了我的问题。
答案 0 :(得分:3)
我没有答案,但我可以为您提供一些调试技巧。
Appstats可能会也可能没有正确报告。但是,日志消息会加上时间戳。记录之前&amp;在每次RPC操作之后。这应该会给你一些见解。
30秒的延迟听起来很像预热请求,应该在日志中清楚标明。我过去发现的一件事是,为低流量应用设置任何常驻实例(不直观)往往会将大量请求路由到冷实例。使用默认设置并设置cron任务以每分钟ping一次端点。