-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
go-micro client rpc-call do not provide the connection pool #64
Comments
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:
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". |
@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. |
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. |
First steps. Benchmarking the transport https://github.com/micro/go-micro/blob/master/transport/http/http_test.go
This is on my horrific 1.7 GHz Intel Core i5 2011 macbook air. |
Just as the subject, go-micro rpc client should provide the connection pool for the target server port.
I change the sample code go-micro/example/client/codegen/codegen.go to test the performance of go-micro rpc.
The changed snippet of code as below:
During the client running, the console will throw exception as below:
I checked the go-micro rpc_client.go code, found that every remote method call will create the tcp/ip connection, and after revocation this connection will be destroied. That will cause bad performance issue in the high load system.
rpc_client.go code snippet:
Hope go-micro client can provide connection pool, only that go-micro can be used in the real production system.
The text was updated successfully, but these errors were encountered: