golang渠道vs.常規產卵性能

Question

如果有人分析了這兩種範例之間的性能差異，我很好奇。

1. 有一個聽衆的goroutine（也許幾個），其監聽套接字，並生成一個新的goroutine來處理信息，並一起到哪裏它去發送。發送命令後，例程將完成並將被銷燬。每個請求都會創建一個例程，然後在完成時將其銷燬。

2. 有一個聽衆的goroutine（也許幾個），其監聽套接字和數據傳遞給一個通道。許多goroutines阻止頻道接收，並將輪流從頻道中取出並處理它們。完成後，例程將在該頻道上等待以獲取更多信息。例程永遠不會在這個範例中被破壞。一對夫婦主程序在頻道上接收套接字信息，其他例程在頻道上等待處理信息。例程永遠不會被破壞。

問題我有用於接收大量的信息小的比特在接收（每個消息0.5-1.5kb），但有很多在未來一次消息的系統（高容量，低尺寸）什麼範例更適合速度和處理。有大量的例程坐在並使用頻道將它們分散到一堆聽力程序中？或者，爲每個請求創建一個路由並在每個請求之後讓該例程結束？

連最基本的思想和猜想是很酷。

謝謝。

Answer 1

一般來說，我傾向於認爲產卵無數的程序，而無需重新使用他們在浪費：即使夠程很便宜，它們不是免費的，並暗示調度成本。

現在，這兩種方法都在高負荷下的缺點：產卵程序將花費你的內存，調度和可研程序停頓，而使用渠道您的要求將掛起，直到前一個被處理。

我通常的做法是做一個基於批處理的管道（由優秀Go Concurrency Patterns: Pipelines and cancellations博客文章的啓發）：

• 監聽器發送請求在一個通道中的緩衝
• 一個聚合例行PUT請求
• N個處理程序請求緩衝溶液的數據塊時，他們可以自由

這樣，你可以精確地控制你的pipeli的流量和行爲ne，同時保持多位工人的優勢。您可以輕鬆地實現通過丟棄進來的請求溢出機制，如果緩衝區獲得超過極限尺寸，產卵或殺死新工人acomodate負載等