gpt4 book ai didi

java - 低负载下 App Engine 一致的延迟峰值

转载 作者:塔克拉玛干 更新时间:2023-11-03 05:24:22 26 4
gpt4 key购买 nike

我注意到我的应用在 App Engine 上运行时出现周期性但一致的延迟峰值。起初我以为网络可能很慢,但应用程序统计数据证实情况并非如此。

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

  • 应用引擎 SDK:1.9.42
  • Google 云端点:1.9.42
  • 客观化: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 我完全被卡住了,我不确定如何调试或修复这个问题,我开始认为这对于 App Engine 上的小型应用来说是正常的。

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

编辑:

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

25 seconds before my code is run

负载仍然很低,这是在预热实例上的请求。

编辑 2:

似乎无论出于何种原因,app 引擎 + 端点都不能很好地与 min-idle-instances 集配合使用。恢复为默认应用引擎配置解决了我的问题。

enter image description here

最佳答案

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

Appstats 可能会或可能不会正确报告。但是,日志消息会加上时间戳。在每个 RPC 操作之前和之后记录。这应该会让您有所了解。

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

关于java - 低负载下 App Engine 一致的延迟峰值,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/40179342/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com