<p>I have been diving into creating something that will scale via the user of a worker pool to asynchronously handle units of work. I first saw a very basic implementation here:
<a href="https://gobyexample.com/worker-pools" rel="nofollow">Go by example worker pools</a></p>
<p>But then later ran across this slightly more complex implementation:
<a href="http://nesv.github.io/golang/2014/02/25/worker-queues-in-go.html" rel="nofollow">nesv worker queues in go</a></p>
<p>and another article talking about how much performance they gained from the second method, which uses a channel of channels.
<a href="http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/" rel="nofollow">malwarebytes go workers</a></p>
<p>I guess my real question as a neophyte is, why would the second implementation outperform the simple one so greatly, either way I feel like workers are accessing a buffered queue as quickly as they can after finishing the previous task. The only different seems to be a channel of workers, that each have their channel of tasks, but I am failing to understand why this is better than just workers working off of a single channel of tasks.</p>
<p>I was hoping someone would be able to explain to me WHY, because I believe I understand both code examples fairly well (but maybe I don't if I am missing why the second would be better).</p>
<hr/>**评论：**<br/><br/>Redundancy_: <pre><p>For a neophyte, my first advice is to worry about doing concurrency correctly before worrying about absolute speed. There are a lot of examples available, and sometimes they skip some important things like how to handle errors or cancel work, which are more complicated questions than you might think.</p>
<p>$0.02 - start with <a href="https://godoc.org/golang.org/x/sync/errgroup#ex-Group--Parallel" rel="nofollow">https://godoc.org/golang.org/x/sync/errgroup#ex-Group--Parallel</a></p></pre>9gPgEpW82IUTRbCzC5qr: <pre><p>just going off of what you described, assuming a worker uses the given channel for multiple jobs, then that worker-specific channel would have much less lock contention than a shared channel for all workers.</p>
<p>actually a really good idea and I'll be investigating it this week to see if we get some easy speed bumps from it</p></pre>
