go-micro client rpc-call do not provide the connection pool

[go-micro]

go-micro client rpc-call do not provide the connection pool

[asim]

This is a bit of a crude example of overloading a server to a point that the host itself cannot provide the resources required to serve the request. If I take the same example and apply it against a basic net/http server it will yield the same result.

Here's a gist https://gist.github.com/asim/11aa2e31ddece57b41bf. And the result:

call err:  Get http://localhost:9099: dial tcp [::1]:9099: socket: too many open files
2016/03/19 10:55:36 http: Accept error: accept tcp [::]:9099: accept: too many open files; retrying in 5ms
call err:  Get http://localhost:9099: EOF
2016/03/19 10:55:36 http: Accept error: accept tcp [::]:9099: accept: too many open files; retrying in 5ms
call err:  Get http://localhost:9099: EOF
2016/03/19 10:55:36 http: Accept error: accept tcp [::]:9099: accept: too many open files; retrying in 10ms
call err:  Get http://localhost:9099: EOF
2016/03/19 10:55:36 http: Accept error: accept tcp [::]:9099: accept: too many open files; retrying in 20ms
call err:  Get http://localhost:9099: EOF

I think its probably first important to determine an appropriate benchmarking test to gauge current performance, then target the bottlenecks. The above is not a test of a "real production system".

[henrypfhu]

@asim, thanks for your quick response. Just as you mentioned, even net/http client request without client connection pool will cause the issue.

My point is that go-micro rpc framework will be more robust and performance boosting to reuse the established long-live connection.

Http2 protocol can be used to keep long-live connection between go-micro rpc client and server. Maybe go-micro can rely on golang.com/x/net/http2/client_conn_pool.go to provide keep-alive long connection feature to boost the performance.

[asim]

I will look into the connection pooling however the thing to remember is that go-micro is a pluggable library made up of a number of components. A client Call will use the client, selector, registry and transport. The server will also make use of the transport. We provide sane defaults but if you want to build performance optimised plugins for each interface you can do this. You're not limited to using the defaults within go-micro. Example plugins are here https://github.com/micro/go-plugins.

Connection pooling is potentially something solved at the transport layer. Either by implementing a new http2 plugin or by adding a connection pooling Option to the existing transport.

[asim]

First steps. Benchmarking the transport https://github.com/micro/go-micro/blob/master/transport/http/http_test.go

go test -bench=. -benchtime=10s
testing: warning: no tests to run
PASS
BenchmarkTransport1-4      50000        277117 ns/op
BenchmarkTransport8-4     100000        190061 ns/op
BenchmarkTransport16-4    100000        186685 ns/op
BenchmarkTransport64-4    100000        194432 ns/op
BenchmarkTransport128-4   100000        251565 ns/op
ok      github.com/micro/go-micro/transport/http    107.467s

This is on my horrific 1.7 GHz Intel Core i5 2011 macbook air.