了解AppEngine的Go运行时的“运行时mcycles”和“cpu_ms”会计

时间:2014-05-01 20:47:36

标签: google-app-engine go

我有一个Go / AppEngine应用程序,我试图微调以优化并发请求,这些请求当前是cpu绑定的。在这样做的过程中,我会在日志中看到cpu_ms的异常值,并在信息中心看到average runtime mcycles

我有一些不同的端点,其cpu使用似乎与现实完全不一致,但其中一个特别突出。它是一个简单的处理程序,大致如下:

    func ThangHandler(w http.ResponseWriter, r *http.Request) {
        ctx := appengine.NewContext(r)

        var orgId string
        cookie, err := r.Cookie(orgCookieKey)
        if err != nil || cookie.Value == "" {
            // Check URL params as a fallback.
            r.ParseForm()
            orgId = r.Form.Get("orgId")
            if orgId == "" {
                util.HttpError(ctx, w, http.StatusForbidden)
                return
            }
        } else {
            orgId = cookie.Value
        }

        w.Header().Set("Content-Type", "application/json; charset=utf-8")
        fmt.Fprintf(w, simpleTemplate, orgId, r.Host, "true", host)
    }

此代码的详细信息并不重要,因为它不仅仅是读取cookie / param并在非常简单的模板字符串上运行Printf(可能是100个字符或以上)左右)。

在我写这篇文章时,AppEngine仪表板报告此端点在过去一小时内的平均消耗83 runtime mcycles,这看起来非常高。当我查看与这些请求相关的前20个日志条目时,我看到一个更奇怪的图片。他们中的大多数都是ms=13 cpu_ms=0ms=13 cpu_ms=21(我假设那里有一些量化)。但是大约10%真的奇数,例如ms=148 cpu_ms=238

所以我的实际问题是:

  • 如此简单的端点如何可能消耗83个平均mcycles,并且具有如此高的方差?
    • 我是否应该怀疑GC暂停?
  • 日志中的cpu_ms > ms如何

1 个答案:

答案 0 :(得分:2)

为了将来遇到这个问题的任何人的利益,这里是dogle在google-appengine-go邮件列表中给出的答案:

  

cpu_ms和相关的会计措施是遗留下来的   旧的结算结构,至少部分基于CPU   消费。如今从这个角度来看,它毫无意义,我   如果这些数字有点荒谬,我们不会感到惊讶。

     

在Go运行时中没有任何内容可以将CPU时间归因于   单独的请求,在并发中也不容易处理   运行。属性是统计性的,可以说明   因为你看到的怪异。