Java Google应用程序引擎-云控制台Stackdriver跟踪详细信息

我试图更好地理解谷歌云控制台Stackdriver跟踪显示呼叫细节的方式，并调试我的应用程序的一些性能问题。 大多数请求都与memcache set/get操作一起工作，我在这里遇到了一些问题，但我不明白的是，为什么调用之间有很长的时间间隔。我上传了2个截图

因此，正如您所看到的，@1025ms的调用花费了2ms，但它与@5235ms的urlfetch调用之间的间隔超过了4秒

首先，我的代码在这一点上并不密集（完整的请求显示大约9000ms的未跟踪时间），其次，运行相同代码的大多数类似请求没有这些间隙（即重复请求没有相同的行为）。但我在其他请求中也看到了这个问题，我无法复制它们

请告知

编辑：

我从appstats上传了另一个截图。这是一个“正常”请求，通常需要几百毫秒才能运行（最多1s），在localhost（开发）中也是如此。我无法找到任何东西来进一步调试。我觉得我错过了一些简单的东西，一些基本的东西，关于应用程序引擎的应该做和不应该做的事情

---

鉴于这种情况很少发生，而且实际处理时间（由跨度长度表示）很短，我怀疑某种应用程序引擎缩放操作正在后台发生。例如，减速可能是由于将新实例添加到应用程序中造成的。您可以通过查看AppEngine仪表板上的活动图或使用AppStats（参见本文）进一步深入了解这一点

---

在“跟踪时间线”视图中显示应用程序引擎事件是我们一段时间以来一直想做的事情，因为这将大大缩短此类情况下的分析过程。

我知道造成此类差距的常见原因（“未跟踪时间”）：

• 在这些间隙期间，请求实际上是CPU受限的
  要检查此问题，请转到日志查看器 并查看受影响的传入HTTP请求的详细信息。注意 从跟踪详细信息到日志还有一个方便的直接链接 进入在请求日志条目中，查找cpu_ms字段，该字段说明
  完成请求所需的CPU毫秒数。这是CPU实际执行应用程序代码所花费的毫秒数，以基线1.2 GHz Intel x86 CPU表示。如果实际使用的CPU快于基线，则CPU毫秒可能大于实际时钟时间[…]。（）
  此指标也可在protoPayload.megaCycles中找到
  下面是一个缓慢请求的示例日志条目，其中包含大量未跟踪的时间：

  2001:... - - [02/Mar/2017:19:20:22 +0100] "GET / HTTP/1.1" 200 660 - "Mozilla/5.0 ..." "example.com" ms=4966 **cpu_ms=11927** cpm_usd=7.376e-8 loading_request=1 instance=... app_engine_release=1.9.48 trace_id=...
  

  对于这个示例请求，cpu_ms字段异常高（11927），表明大部分未跟踪的时间都花在应用程序本身（或运行时）上
  为什么请求处理程序使用那么多CPU？通常，几乎不可能准确地说出CPU时间花在了什么地方，但是如果您知道给定请求中应该发生什么，您可以更容易地缩小它的范围。两个常见的原因是：
  • 这是对新启动的应用程序引擎实例的第一个请求。JVM需要加载类和JIT编译热方法——这将显著影响第一个请求（可能还会影响更多）。在请求日志条目中查找加载请求=1以检查您的请求是否因此而变慢。考虑一下，
    Protip，如果您想集中调查筛选出日志查看器中的加载请求，请应用此高级筛选：

    protoPayload.megaCycles > 10000 and protoPayload.wasLoadingRequest=false
    

  • 应用程序代码的某些部分由于过度使用反射而大大降低了速度。这是特定于应用程序引擎标准环境的，其中安全管理器限制反射的使用。唯一的缓解措施是减少反射。请注意，应用程序引擎服务的基础设施正在不断发展，因此这一提示可能很快就会过时
    如果这个问题在dev appserver中可以在本地重现，那么可以使用探查器（或者可能只是jstack）来缩小范围。在其他一些情况下，我必须逐步地将应用程序代码一分为二，添加更多日志语句，重新部署，等等，直到发现有问题的代码

• 实际上，在App Engine标准环境中，有一些未跟踪的后端调用未被Stackdriver跟踪覆盖。到目前为止，我知道的唯一一个例子是云SQL。考虑使用以获得与云SQL跟踪的交互。

• 该应用程序是多线程的（很棒！），并且会遇到一些自我造成的同步问题。我在野外看到的例子：
  • 特定于应用程序的同步强制对存储后端的所有请求进行序列化（对于给定的应用程序引擎实例）。除了那些神秘的缺口，痕迹中什么也看不出来
  • 应用程序使用数据库连接池。并行请求的数量超过池的容量（对于给定的应用程序引擎实例），有些请求必须等待连接可用。这是前一项的更复杂变化

---

我知道激活AppStats会对应用程序的性能产生影响，Stakdriver跟踪也是如此吗？否-GAE上的跟踪功能内置于语言运行时中，不会对应用程序的性能产生明显影响。这意味着要在大规模的生产中运行，我们只对每个服务收到的请求的一小部分进行采样。嗨，摩根，我已经激活了appstats，但我似乎找不到可以进一步使用的东西（我已经编辑了我的帖子）。