Skip to content

N
net
Switch branch/tag
  1. 21 Apr, 2017 1 commit
  3. 13 Apr, 2017 1 commit
  5. 06 Apr, 2017 1 commit
  7. 29 Mar, 2017 2 commits
  9. 28 Mar, 2017 2 commits
  11. 24 Mar, 2017 2 commits
  13. 23 Mar, 2017 1 commit
  15. 08 Mar, 2017 2 commits
  17. 03 Mar, 2017 1 commit
    • Ian Gudger's avatar
      dns/dnsmessage: add support for parsing and packing of DNS messages · d379faa2
      Ian Gudger authored 
      The Go standard library contains support for packing and unpacking of
DNS messages, but it is not exported, doesn't follow Go style, and is
not very well optimized. Low level DNS functionality is clearly useful
to the Go community as evidenced by the success of
github.com/miekg/dns. This implementation endeavors to avoid the
limitations of both the standard library and github.com/miekg/dns
implementations and is an almost complete rewrite of the code
currently found in on net/dnsmsg.go and net/dnsmsg_test.go.

Goals:
* Minimize heap allocations.
* Allow parsing only what is needed. Avoid unnecessary parsing and
  heap allocations for parts of the message that you don't care about.
  Parsing should be allowed on as small of a granularity as is useful,
  but no smaller as to avoid complicating the interface.
* Parse and pack each byte of the message at most one time.

Updates golang/go#16218
Updates golang/go#10622

Change-Id: Ib754d0007609a617d88be867f21c2feb15b6fcd7
Reviewed-on: https://go-review.googlesource.com/35237
Run-TryBot: Mikio Hara <mikioh.mikioh@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarMikio Hara <mikioh.mikioh@gmail.com>
      d379faa2
  19. 27 Feb, 2017 3 commits
    • Tom Bergan's avatar
      http2: add configurable knobs for the server's receive window · 906cda95
      Tom Bergan authored 
      Upload performance is poor when BDP is higher than the flow-control window.
Previously, the server's receive window was fixed at 64KB, which resulted in
very poor performance for high-BDP links. The receive window now defaults to
1MB and is configurable. The per-connection and per-stream windows are
configurable separately (both default to 1MB as suggested in golang/go#16512).

Previously, the server created a "fixedBuffer" for each request body. This is no
longer a good idea because a fixedBuffer has fixed size, which means individual
streams cannot use varying amounts of the available connection window. To
overcome this limitation, I replaced fixedBuffer with "dataBuffer", which grows
and shrinks based on current usage. The worst-case fragmentation of dataBuffer
is 32KB wasted memory per stream, but I expect that worst-case will be rare.

A slightly modified version of adg@'s grpcbench program shows a dramatic
improvement when increasing from a 64KB window to a 1MB window, especially at
higher latencies (i.e., higher BDPs). Network latency was simulated with netem,
e.g., `tc qdisc add dev lo root netem delay 16ms`.

Duration        Latency Proto           H2 Window

11ms±4.05ms     0s      HTTP/1.1        -
17ms±1.95ms     0s      HTTP/2.0        65535
8ms±1.75ms      0s      HTTP/2.0        1048576

10ms±1.49ms     1ms     HTTP/1.1        -
47ms±2.91ms     1ms     HTTP/2.0        65535
10ms±1.77ms     1ms     HTTP/2.0        1048576

15ms±1.69ms     2ms     HTTP/1.1        -
88ms±11.29ms    2ms     HTTP/2.0        65535
15ms±1.18ms     2ms     HTTP/2.0        1048576

23ms±1.42ms     4ms     HTTP/1.1        -
152ms±0.77ms    4ms     HTTP/2.0        65535
23ms±0.94ms     4ms     HTTP/2.0        1048576

40ms±1.54ms     8ms     HTTP/1.1        -
288ms±1.67ms    8ms     HTTP/2.0        65535
39ms±1.29ms     8ms     HTTP/2.0        1048576

72ms±1.13ms     16ms    HTTP/1.1        -
559ms±0.68ms    16ms    HTTP/2.0        65535
71ms±1.12ms     16ms    HTTP/2.0        1048576

136ms±1.15ms    32ms    HTTP/1.1        -
1104ms±1.62ms   32ms    HTTP/2.0        65535
135ms±0.96ms    32ms    HTTP/2.0        1048576

264ms±0.95ms    64ms    HTTP/1.1        -
2191ms±2.08ms   64ms    HTTP/2.0        65535
263ms±1.57ms    64ms    HTTP/2.0        1048576

Fixes golang/go#16512
Updates golang/go#17985
Updates golang/go#18404

Change-Id: Ied385aa94588337e98dad9475cf2ece2f39ba346
Reviewed-on: https://go-review.googlesource.com/37226Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
      906cda95
    • Tom Bergan's avatar
      http2/hpack: speedup Encoder.searchTable · bce15e71
      Tom Bergan authored 
      The previous algorithm was linear in the size of the table.
The new algorithm is O(1). The new algorithm should behave exactly
like the old algorthm, except for one unimportant change that
triggered small updates to tests in encode_test.go:

When encoding "Field: Value" where the table has two entries,
[0]={"Field", "X"} and [1]={"Field", "Y"}, we can encode the field
name using either table entry. Previously, we selected the oldest
entry, but now we select the newest entry. The new implementation
should actually generate very slightly better compression because
new entries are encoded with smaller integers than old entries, and
HPACK uses a varint encoding for integers where smaller integers
are encoded in fewer bytes.

I added a synthetic microbenchmark which shows a big speedup in
hpack.Encoder.searchTable:

BenchmarkEncoderSearchTable-40  100000 127440 ns/op  # before
BenchmarkEncoderSearchTable-40   50000  25121 ns/op  # after

Change-Id: Ib87d61b6415d9f0ff38874fe2a719b2f00351590
Reviewed-on: https://go-review.googlesource.com/37406Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      bce15e71
    • Alexander Polcyn's avatar
      http2: Add opt-in option to Framer to allow DataFrame struct reuse · bb807669
      Alexander Polcyn authored 
      The existing Framer in net/http2 allocates a new DataFrame struct
for each DataFrame read on calls to ReadFrame. The SetReuseFrame
option introduced here, if set on a Framer, allows the
Framer to reuse Frame objects and changes the ReadFrame API
so that returned Frame objects are only valid until the next call
to ReadFrame. This opt-in API now only implements reuse of DataFrames,
but it allows the Framer to reuse of any type of Frame.

The footprint caused by creation of new DataFrame structs per data
frame was noticed in micro benchmarks of "gRPC" server "streaming
throuhgput", which uses the Framer in this package. This benchmark
happened to use long lived http2 streams that do client-server "ping-pong"
requests with small data frames, and DataFrames were seen to be a
significant source of allocations.

Running local benchmarks with: (from x/net/http2 directory)

$ go test -run=^$ -bench=BenchmarkServerToClientStream

example output:
* expect an alloc reduction of at least 1 and a small memory reduction between
"BenchmarkServerToClientStreamDefaultOptions" and
"BenchmarkServerToClientStreamReuseFrames"

BenchmarkServerToClientStreamDefaultOptions-12    	   30000
46216 ns/op	     971 B/op	      17 allocs/op
BenchmarkServerToClientStreamReuseFrames-12       	   30000
44952 ns/op	     924 B/op	      16 allocs/op

Fixes golang/go#18502

Change-Id: Iad93420ef6c3918f54249d867098f1dadfa324d8
Reviewed-on: https://go-review.googlesource.com/34812
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      bb807669
  21. 24 Feb, 2017 1 commit
    • Tom Bergan's avatar
      http2: replace fixedBuffer with dataBuffer · 10c134ea
      Tom Bergan authored 
      fixedBuffer was a bad idea for two reasons:

1. It was fixed at a constant 64KB (the current default flow-control
   window) which wastes memory on the server when clients upload many
   small request bodies.

2. A follow-up CL will allow configuring the server's connection and
   stream receive windows. We want to allow individual streams to use
   varying amounts of the available connection window. This is not
   possible when each stream uses a fixedBuffer.

dataBuffer grows and shrinks based on current usage. The worst-case
fragmentation of dataBuffer is 32KB wasted memory per stream, but I
expect that worst-case will be rare. In particular, if the declared
size of a stream's request body is under 1KB, then the server will not
allocate more than 1KB to process that stream's request body.

Updates golang/go#16512
Fixes golang/go#18509

Change-Id: Ibcb18007037e82518a65848ef3baf4937955ac9d
Reviewed-on: https://go-review.googlesource.com/37400
Run-TryBot: Tom Bergan <tombergan@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: 's avatarBrad Fitzpatrick <bradfitz@golang.org>
      10c134ea
  23. 23 Feb, 2017 2 commits
  25. 18 Feb, 2017 2 commits
  27. 15 Feb, 2017 1 commit
  29. 11 Feb, 2017 1 commit
  31. 09 Feb, 2017 2 commits
  33. 06 Feb, 2017 2 commits
  35. 03 Feb, 2017 1 commit
  37. 01 Feb, 2017 2 commits
  39. 14 Jan, 2017 1 commit
  41. 13 Jan, 2017 3 commits
  43. 10 Jan, 2017 3 commits
  45. 09 Jan, 2017 3 commits