Conversation
7c44bfe to
2c23efd
Compare
2c23efd to
91f5968
Compare
src/code.cloudfoundry.org/gorouter/proxy/round_tripper/proxy_round_tripper.go
Outdated
Show resolved
Hide resolved
e9cbe0c to
7b456f8
Compare
9f21f6b to
513c575
Compare
peanball
left a comment
There was a problem hiding this comment.
First set of comments. I have not looked at the implementation of maglev and the hash based instance determination.
I've focussed on the integration with the existing Gorouter code, route lookup, LB algo handling, etc.
5030bbc to
560f935
Compare
peanball
left a comment
There was a problem hiding this comment.
Some more comments, now on the hash_based.go
|
LGTM. Once we have the performance tests, we should move to community review. |
|
Good news - we evaluated the performance of gorouter with hash-based routing support. Our test setup constists of scaled out HAProxy (as a load balancer in front of gorouter), scaled out Diego Cells and a very simple and performant application with 30 instances. This allows us to performance test gorouter via external requests, where gorouter is the bottleneck. We compared the performance of the latest stable routing-release, and the same release including changes from this Pull-Request. Using
We also explored that requests are routed to next instances as expected, when the max. connection limit of one app instance was reached. The hash_balance factor is effective and allows distribution of requests to next instances before overloading it. Please feel free to reach out for details on the results! |
Changes were addressed. As this is still subject to change, I cannot give "final" approval yet.
21cc8b7 to
b414a38
Compare
|
During performance tests, we figured out that the Gorouter memory consumption is higher than expected if we keep the permutation table (table which is used to fill the final maglev lookup table) in memory. We want to investigate this finding further and optimize it. |
hoffmaen
left a comment
There was a problem hiding this comment.
Only documentation / log related comments.
Hello, I am requesting approver status for the Networking group. My contributions so far: Pull-Requests: cloudfoundry/gorouter#442 cloudfoundry/gorouter#435 cloudfoundry/routing-release#519 cloudfoundry/routing-release#514 cloudfoundry/routing-release#504 cloudfoundry/routing-release#453 cloudfoundry/routing-release#434 cloudfoundry/cli#3378 cloudfoundry/cloud_controller_ng#4080 cloudfoundry/cloud_controller_ng#4199 Co-Authorship: cloudfoundry/routing-release#478 Pull-Request Reviews: cloudfoundry/gorouter#443 cloudfoundry/routing-release#452 cloudfoundry/cli#3372 GitHub Issues: cloudfoundry/routing-release#529 cloudfoundry/routing-release#468 cloudfoundry/routing-release#445 cloudfoundry/routing-release#429 cloudfoundry/cloud_controller_ng#4198
This commit provides the basic implementation for hash-based routing. It does not consider the balance factor yet. Co-authored-by: Clemens Hoffmann <clemens.hoffmann@sap.com> Co-authored-by: Tamara Boehm <tamara.boehm@sap.com> Co-authored-by: Soha Alboghdady <soha.alboghdady@sap.com>
Co-authored-by: Alexander Nicke <alexander.nicke@sap.com>
d21580f to
cd304af
Compare
cd304af to
69da88c
Compare
|
Please make sure to compact the history before merging. |
| router.hash_based_routing.lookup_table_size: | ||
| description: | | ||
| Size of the Maglev lookup table used for hash-based load balancing. | ||
| The size should be approximately chosen based on the expected maximum number of endpoints / application instances per route which use hash-based routing. The provided values are not hard limits but recommended values. |
There was a problem hiding this comment.
You say that they are not hard limits, yet you prevent the operator from choosing their own value. Wouldn't an integer and a comment explaining the rough ranges be a better approach here?
There was a problem hiding this comment.
We assumed that it could be difficult for operators to determine the exact value for this table size.
However, the current "t-shirt size" approach is an MVP for this first pass and may be refined as we gather more data. We are still discussing internally how to dynamically calculate the maglev lookup table size based on endpoint numbers, rather than defining a static configuration value via the routing release.
| LoadBalancingAlgorithm string `json:"loadbalancing"` | ||
| HashHeaderName string `json:"hash_header"` | ||
| HashBalance float64 `json:"hash_balance"` | ||
| HashBalance float64 `json:"hash_balance,string"` |
There was a problem hiding this comment.
Why isn't this just a number in the JSON that we are parsing?
There was a problem hiding this comment.
@hoffmaen
Could you remember why we changed to string?
There was a problem hiding this comment.
Yes. This is because route-emitter sends the value as a string. We didn't want to make changes to route-emitter, and having the value as a string has no practical downsides.
This is also the implementation in cloud-controller
Summary
This Pull-Request implements #505.
Backward Compatibility
Breaking Change? Yes/No