3 ms·

Fast HTTP package for Go

7 points by Spiritus 11y ago

infogulch 11y ago
One thing that stood out to me is that allocations were reduced from 18-30 per op down to zero across the board. I'd be interested in the techniques they used to achieve this, and if any could be applied to the standard library itself. Also, a benchcmp would be nice.
- pxue 11y ago
  sync.pools aka buffer pools. this puts lots of back pressure on GC trading bursts of speed for a more noticeable pause at a later time bc of the pause-the-world style GC. I'd love to see if this is still the case with the GC improvements in Go 1.5+. One solution is to manually load balance your web services to switch seamlessly between GC pauses (stagnated gc), without this it's almost unusable in real time applications.
  - infogulch 11y ago
    Yeah I thought sync.Pool might be involved. But I don't see how this would negatively impact the GC, since using a pool almost always reduces the amount of garbage.
    - pxue 11y ago
      Unlike in C you can't tell the garbage collector to "ignore" a large chunk of the memory allocated in the buffer. what ends up happening is Go's GC spends lots of time traversing the heap and marking anyway and end up doing nothing. I know they've made optimizations like here https://github.com/golang/go/issues/9477 https://github.com/golang/go/issues/9477 but I haven't followed it up and gave it another look yet.
- infogulch 11y ago
  By the way, here is the benchcmp copied from the results in the README (and renaming them so benchcmp works properly), omitting allocs and bytes because that's already pretty clear. First, GOMAXPROCS=1: benchmark old ns/op new ns/op delta BenchmarkServerGet1ReqPerConn 21211 2495 -88.24% BenchmarkServerGet2ReqPerConn 15682 1925 -87.72% BenchmarkServerGet10ReqPerConn 9957 1300 -86.94% BenchmarkServerGet10KReqPerConn 8243 1140 -86.17% BenchmarkServerGet1ReqPerConn1KClients 23474 2460 -89.52% BenchmarkServerGet2ReqPerConn1KClients 18124 1962 -89.17% BenchmarkServerGet10ReqPerConn1KClients 11815 1340 -88.66% BenchmarkServerGet10KReqPerConn1KClients 9106 1180 -87.04% GOMAXPROCS=4: benchmark old ns/op new ns/op delta BenchmarkServerGet1ReqPerConn-4 5929 1094 -81.55% BenchmarkServerGet2ReqPerConn-4 4153 707 -82.98% BenchmarkServerGet10ReqPerConn-4 2751 417 -84.84% BenchmarkServerGet10KReqPerConn-4 2398 351 -85.36% BenchmarkServerGet1ReqPerConn1KClients-4 5979 916 -84.68% BenchmarkServerGet2ReqPerConn1KClients-4 4582 655 -85.70% BenchmarkServerGet10ReqPerConn1KClients-4 3589 404 -88.74% BenchmarkServerGet10KReqPerConn1KClients-4 2465 359 -85.44%
nnx 11y ago
Is it 100% drop-in replacement of net/http?

7 points by Spiritus 11y ago

One thing that stood out to me is that allocations were reduced from 18-30 per op down to zero across the board. I'd be interested in the techniques they used to achieve this, and if any could be applied to the standard library itself. Also, a benchcmp would be nice.

pxue 11y ago
sync.pools aka buffer pools. this puts lots of back pressure on GC trading bursts of speed for a more noticeable pause at a later time bc of the pause-the-world style GC. I'd love to see if this is still the case with the GC improvements in Go 1.5+. One solution is to manually load balance your web services to switch seamlessly between GC pauses (stagnated gc), without this it's almost unusable in real time applications.
- infogulch 11y ago
  Yeah I thought sync.Pool might be involved. But I don't see how this would negatively impact the GC, since using a pool almost always reduces the amount of garbage.
  - pxue 11y ago
    Unlike in C you can't tell the garbage collector to "ignore" a large chunk of the memory allocated in the buffer. what ends up happening is Go's GC spends lots of time traversing the heap and marking anyway and end up doing nothing. I know they've made optimizations like here https://github.com/golang/go/issues/9477 https://github.com/golang/go/issues/9477 but I haven't followed it up and gave it another look yet.
infogulch 11y ago
By the way, here is the benchcmp copied from the results in the README (and renaming them so benchcmp works properly), omitting allocs and bytes because that's already pretty clear. First, GOMAXPROCS=1: benchmark old ns/op new ns/op delta BenchmarkServerGet1ReqPerConn 21211 2495 -88.24% BenchmarkServerGet2ReqPerConn 15682 1925 -87.72% BenchmarkServerGet10ReqPerConn 9957 1300 -86.94% BenchmarkServerGet10KReqPerConn 8243 1140 -86.17% BenchmarkServerGet1ReqPerConn1KClients 23474 2460 -89.52% BenchmarkServerGet2ReqPerConn1KClients 18124 1962 -89.17% BenchmarkServerGet10ReqPerConn1KClients 11815 1340 -88.66% BenchmarkServerGet10KReqPerConn1KClients 9106 1180 -87.04% GOMAXPROCS=4: benchmark old ns/op new ns/op delta BenchmarkServerGet1ReqPerConn-4 5929 1094 -81.55% BenchmarkServerGet2ReqPerConn-4 4153 707 -82.98% BenchmarkServerGet10ReqPerConn-4 2751 417 -84.84% BenchmarkServerGet10KReqPerConn-4 2398 351 -85.36% BenchmarkServerGet1ReqPerConn1KClients-4 5979 916 -84.68% BenchmarkServerGet2ReqPerConn1KClients-4 4582 655 -85.70% BenchmarkServerGet10ReqPerConn1KClients-4 3589 404 -88.74% BenchmarkServerGet10KReqPerConn1KClients-4 2465 359 -85.44%

nnx 11y ago

Is it 100% drop-in replacement of net/http?