Question

我有一个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=0或ms=13 cpu_ms=21（我假设那里有一些量化）。但是大约10％真的奇数，例如ms=148 cpu_ms=238！

所以我的实际问题是：

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

Answer 1

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

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

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

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

1 个答案: