2 ms·
Since this heavily involves networking, take a look into using gnet [0]. You might find some interesting performance improvements by using that over just net.Co
by latchkey 4y ago
Since this heavily involves networking, take a look into using gnet [0]. You might find some interesting performance improvements by using that over just net.Conn.
[0] https://github.com/panjf2000/gnet https://github.com/panjf2000/gnet
- pojntfx 4y agoThanks, I had not heard of that package, I will be sure to check it out!
- tptacek 4y agoProbably wouldn't do this unless you really needed to; nbd workloads are probably easier than HTTP workloads (a single NBD "mount" might have lots of connections, but you're not adding and removing hundres of connections per second).
- latchkey 4y agoYou might be right. Different workloads will definitely have different effects. That said, implementing the gnet api is pretty easy and doesn't require a huge context switch. It is worth a test to see which one performs better. I used it for a tcp connection (json-rpc) workload and it was far better and the code was cleaner.
- tptacek 4y agoRight, I don't want to talk down gnet, it's neat, but you're basically writing non-idiomatic libevent-style networking code --- ie, very non-idiomatic Go code --- and it seems to me like most of the perf win here is minimizing the number of goroutines you have serving blocking operations, which is not really a problem you're going to have with an NBD implementation.
- latchkey 4y agoI see your point. In my case it was basically a proxy concentrator. On one side, accept and hold open a huge number of connections, then maintain a single open connection on the other side. It worked really well for this situation.