* First commit
* Imported tests from the original PR by @apolcyn.
* Formatting fixes.
* More formating fixes
* more golint
* Make logs more informative.
* post-review update
* Added test to check flow control accounts after sending large messages.
* post-review update
* Empty commit to kickstart travis.
* Post-review update.
This change saves a lot of memory by reusing the underlying
gzip.{Writer,Reader}, which allocates up to 1.4mb at every instanciation
according to [1]. This was fixed by adding a Reset method by to the
object at [2].
The amount of memory (and GC time) saved is pretty high, as reported by
pprof:
flat flat% sum% cum cum%
28.33GB 85.70% 85.70% 32.74GB 99.05% compress/flate.NewWriter
flat flat% sum% cum cum%
19.39MB 16.74% 16.74% 22.07MB 19.05% compress/flate.NewWriter
And the benchmarks:
benchmark old ns/op new ns/op delta
BenchmarkGZIPCompressor1B-4 215170 22291 -89.64%
BenchmarkGZIPCompressor1KiB-4 225971 27213 -87.96%
BenchmarkGZIPCompressor8KiB-4 246696 54785 -77.79%
BenchmarkGZIPCompressor64KiB-4 444851 286924 -35.50%
BenchmarkGZIPCompressor512KiB-4 2279043 2115863 -7.16%
BenchmarkGZIPCompressor1MiB-4 4412989 4258635 -3.50%
benchmark old allocs new allocs delta
BenchmarkGZIPCompressor1B-4 17 0 -100.00%
BenchmarkGZIPCompressor1KiB-4 17 0 -100.00%
BenchmarkGZIPCompressor8KiB-4 17 0 -100.00%
BenchmarkGZIPCompressor64KiB-4 17 0 -100.00%
BenchmarkGZIPCompressor512KiB-4 17 0 -100.00%
BenchmarkGZIPCompressor1MiB-4 17 0 -100.00%
benchmark old bytes new bytes delta
BenchmarkGZIPCompressor1B-4 813872 8 -100.00%
BenchmarkGZIPCompressor1KiB-4 813872 16 -100.00%
BenchmarkGZIPCompressor8KiB-4 813875 27 -100.00%
BenchmarkGZIPCompressor64KiB-4 813918 190 -99.98%
BenchmarkGZIPCompressor512KiB-4 814928 1871 -99.77%
BenchmarkGZIPCompressor1MiB-4 820889 9735 -98.81%
[1] https://github.com/golang/go/issues/6138
[2] db12f9d4e4
Signed-off-by: Steeve Morin <steeve.morin@gmail.com>
When an error implemented by the status package is returned from a service
handler, the server will transmit a rich status message in the
"grpc-status-details-bin" trailing metadata field if any detailed data is
attached to the error. Client-side, we will decode them if present in the
server's response and return them to the user code performing the RPC.
This is backward compatible with the existing errors supported by the grpc
package. However, the grpc.Errorf, grpc.Code and grpc.ErrorDesc functions for
managing errors are now deprecated; status.Errorf and status.Status type
asserions should be used instead.
The http.Handler-based transport body reader was returning error types
not understood by the recvMsg parser. See #557 for some background and
examples.
Fix the http.Handler transport and add tests. I copied in a subset of
the http2 package's serverTest type, adapted slightly to work with
grpc. In the process of adding tests, I discovered that
ErrUnexpectedEOF was also not handled by the regular server
transport. Document the rules and fix that crash as well.
Unrelated stuff in this CL:
* make tests listen on localhost:0 instead of :0, to avoid Mac firewall
pop-up dialogs.
* rename parser.s field to parser.r, to be more idiomatic that it's an
io.Reader and not anything fancier. (it's not acting like type
stream, even if that's the typical concrete type)
* move 5 byte temp buffer into parser, rather than allocating it for
each new message. (drop in the bucket improvement in garbage; more
to do later)
* rename http2RSTErrConvTab to http2ErrConvTab, per Qi's earlier
CL. Also add the HTTP/1.1-required error mapping for completeness,
not that it should ever arise with gRPC, also per Qi's earlier CL
referenced in #557.
recvMsg was interpreting buf[1] as the payload format instead of buf[0];
since compressionNone (the only thing supported) == 0, recvMsg got lucky
for message lengths under 2^24, which has buf[1] == 0.
Fix the error, and ditch the constants in recvMsg. I think they were the
cause of the bug.
Also make encode fail more clearly if someone tries to transmit a
message that exceeds 2^32 bytes.
Fixes#399.
This commit introduces the first microbenchmark for grpc, wherein
`encode` is benchmarked according to message size. A conclusion of
the benchmark is that the removal of type switching found in
`binary.Write`, which is used in `encode` produces the following
encoding time and memory allocation footprint:
```
$ # Return to previous commit but benchmark.
$ go test ./... -test.bench="Benchmark*" > /tmp/before
$ # Return to working copy.
$ go test ./... -test.bench="Benchmark*" > /tmp/after
$ benchcmp /tmp/before /tmp/after
benchmark old ns/op new ns/op delta
BenchmarkEncode1B 1282 936 -26.99%
BenchmarkEncode1KiB 4865 4184 -14.00%
BenchmarkEncode8KiB 22686 21560 -4.96%
BenchmarkEncode64KiB 134451 116762 -13.16%
BenchmarkEncode512KiB 514044 361224 -29.73%
BenchmarkEncode1MiB 767096 636725 -17.00%
benchmark old MB/s new MB/s speedup
BenchmarkEncode1B 6.24 8.55 1.37x
BenchmarkEncode1KiB 212.11 246.63 1.16x
BenchmarkEncode8KiB 361.46 380.33 1.05x
BenchmarkEncode64KiB 487.50 561.35 1.15x
BenchmarkEncode512KiB 1019.94 1451.45 1.42x
BenchmarkEncode1MiB 1366.95 1646.84 1.20x
benchmark old allocs new allocs delta
BenchmarkEncode1B 6 3 -50.00%
BenchmarkEncode1KiB 8 5 -37.50%
BenchmarkEncode8KiB 8 5 -37.50%
BenchmarkEncode64KiB 8 5 -37.50%
BenchmarkEncode512KiB 8 5 -37.50%
BenchmarkEncode1MiB 8 5 -37.50%
benchmark old bytes new bytes delta
BenchmarkEncode1B 384 328 -14.58%
BenchmarkEncode1KiB 2816 2760 -1.99%
BenchmarkEncode8KiB 17283 17227 -0.32%
BenchmarkEncode64KiB 147856 147802 -0.04%
BenchmarkEncode512KiB 1065344 1065288 -0.01%
BenchmarkEncode1MiB 2113920 2113864 -0.00%
```
..., which is apropos of the comment in [encoding/binary]
(http://golang.org/pkg/encoding/binary), wherein ...
> This package favors simplicity over efficiency.
... is stated.
If `encode` is deemed to need further memory efficiencies, a mechanism
whereby a `proto.Buffer` is retained may be warranted, which is why the
original TODO remains. The proposed improvement in this change is
simple and low-hanging.
I did not want to introduce yet-another protocol buffer message for
tests, but the ones under ...
> interop/grpc_testing/test.proto
> test/grpc_testing/test.proto
... have a fundamental dependency on `grpc` package due to their
generated stubs, which produces a cycle in the imports if the benchmark
were to attempt to import them for profiling. The newly created ...
> test/grpc_message/test.proto
... protocol buffer package has no generated RPC service stubs, which
means it can be imported into the `grpc` package root without cycle.
dfawley
ZhouyihaiDing
MakMukhi
Jan Tattermusch
Mehrdad Afshari
Steeve Morin
Menghan Li
iamqizhao
Tamir Duberstein
Daniel Ruehle
Brad Fitzpatrick
David Symonds
Matt T. Proud