4 ms·
An issue with Go channels and high-performance networking from 2016: "There was one fundamental mistake made, however, which is that we shouldn't have used cha
by spenrose 8y ago
An issue with Go channels and high-performance networking from 2016:
"There was one fundamental mistake made, however, which is that we shouldn't have used channels. ... First, they don't perform well enough. ... Second, they make it very hard to prevent message loss. ... Third, the buffered channels mean that Heka consumes much more RAM than would be otherwise needed"
https://mail.mozilla.org/pipermail/heka/2016-May/001059.html https://mail.mozilla.org/pipermail/heka/2016-May/001059.html
- cdoxsey 8y agoNot really a networking issue. Channels are (relatively) inefficient for small payloads. With a decent payload size they're almost never the bottleneck in a real-world program. You really have to benchmark it. It sounds like in this case the message-loss-prevention rendered the original design flawed. I don't see any reason why you couldn't use an on-disk queue in Go vs other languages... though the cgo overhead of the lua binding sounds like it was also an issue.