performance - 如何判断 go channel 的哪一边正在等待？

Question

如何确定 go channel 的哪一侧正在等待另一侧？

我想知道这一点，以便找出我的处理受限的地方，并通过分配更多资源来做出响应。

一些选项

我想到的两种方法都需要对记录值进行移动平均，这样测量就不会太嘈杂，但这不是 big problem .

---

1. 使用计时器检查消费者等待时间的百分比

在单个消费者的情况下，我可以在从 channel 消费之前启动一个计时器，在我获得记录后停止计时器。我可以跟踪等待时间的百分比，并在每个获取周期内做出相应响应。

1. 缓冲 channel 的样本长度

如果 channel 经常为 0，则意味着我们的消费速度比发送速度快。同样，如果缓冲区已满，我们发送的速度将比接收速度快。我们可以随时间检查 channel 的长度，以确定运行缓慢的原因。

---

出于性能原因或其他原因，是否有充分的理由更喜欢其中之一？这个问题有更简单的解决方案吗？

例子

我有一项服务正在执行 N 个 HTTP 请求，以同时在最多 W 个 goroutine 中获取内容，并将所有内容发送到一个 channel processor 在单个 goroutine 中运行，然后将数据反馈给客户端。

每个工作任务都会导致 channel 上发送大量消息。每个 worker 的任务可能需要几分钟才能完成。

下图总结了 3 个并发工作器 (W=3) 的数据流。

    [worker: task 1] -
                      \
    [worker: task 2] - | --- [ channel ] --- [ processor ] -> [ client ]
                      /
    [worker: task 3] -

我想知道在请求期间我是应该运行更多的 worker(增加 W)还是更少的 worker(减少 W)。由于客户端在速度非常不同的连接上工作，因此每个请求可能会有很大差异。

Answer 1

实现目标的一种方法是使用“有界发送”和“有界接收”操作——如果您能够想出合理的轮询超时。

当您的任何一个工作人员试图通过 channel 发送完成的结果时，不要让它“永远”阻塞(直到 channel 缓冲区中有空间)；相反，只允许它阻塞一些最长时间。如果在 channel 缓冲区中有空间之前发生超时，您可以对这种情况使用react:计算它发生的次数、调整 future 的截止日期、限制或减少工作人员数量，等等。

同样，对于从工作人员接收结果的“处理器”，您可以限制它阻塞的时间。如果在有可用值之前发生超时，则处理器处于饥饿状态。创建更多 worker 以更快地喂养它(假设 worker 将从这种并行性中受益)。

这种方法的缺点是 creating timers 中的开销对于每个 send或 receive operation .

绘制草图，每个 worker 都可以访问这些声明:

const minWorkers = 3
var workers uint32

在每个 worker goroutine 中:

atomic.AddUint32(&workers, 1)
for {
    result, ok := produce()
    if !ok {
        break
    }
    // Detect when channel "p"'s buffer is full.
    select {
    case p <- result:
    case <-time.After(500 * time.Millisecond):
        // Hand over the pending result, no matter how long it takes.
        p <- result
        // Reduce worker count if above minimum.
        if current := atomic.LoadUint32(&workers); current > minWorkers &&
            atomic.CompareAndSwapUint32(&workers, current, current-1) {
            return
        }
        // Consider whether to try decrementing the working count again
        // if we're still above the minimum. It's possible another one
        // of the workers also exited voluntarily, changing the count.
    }
}
atomic.AddUint32(&workers, -1)

请注意，如上所述，您可以通过计时发送到 channel p 完成所需的时间，并对其花费太长时间使用react，而不是执行一个有界发送，然后是一个潜在的阻塞发送。但是，我是这样画的，因为我怀疑这样的代码会成熟到在超时到期时包含日志记录和检测计数器颠簸。

类似地，在您的处理器 goroutine 中，您可以限制阻止从 worker 接收值的时间量:

for {
    select {
    case result <- p:
        consume(result)
    case <-time.After(500 * time.Millisecond):
        maybeStartAnotherWorker()
    }
}

显然，您可以在这个装置上安装许多旋钮。您最终将生产者的调度耦合到消费者和生产者本身。引入一个不透明的“监听器”，生产者和消费者可以向其“提示”延迟，这样您就可以打破这种循环关系，并更轻松地改变管理您如何应对拥塞的策略。