Increase bindcache capacity #457
Conversation
|
How did we settle on these numbers (besides their being 10x the old ones)? |
|
Good question. We want the cache capacity to be big enough to accommodate the number of distinct paths and bounds that linkerd will be receiving. In practice, I don't really know what that is. I pulled the 500 paths number out of thin air, but it feels like the right ballpark. I welcome any input, though. |
|
⭐ though, we should follow up with easier to understand documentation about these parameters for users |
|
I've bumped the linkerd binding cache size down to 100 and the namerd binding cache size up to 1000. This is a configuration I've load tested and am confidant works. It should also be sufficient for small/medium sized organizations. A total of 1000 logical names is probably plenty for many use cases. I've also made all of these parameters configurable for those who these defaults aren't sufficient. |
|
filed #463 as well |
|
This looks good. I still suspect the DstBindingFactory capacities are slightly on the low side -- certainly conceivable that modest-sized deployments could hit these limits. Also, I'm curious how the namerd sizes relate to linkerd capacities -- right now the linkerd capacity is 1/10th the size of the namerd capacity. What's the motivation for limiting namerd caches at 100/10 -- was there any notable difference from 500/50? |
|
linkerd was certainly able to handle a DstBindingFactory path cache of size 500 no problem. My motivation for sizing this down was that a) in a side-car model, I'd imagine that any particular linkerd wouldn't target very many logical paths. i.e. the number of logical downstreams of a service is probably < 100 (or at least that's my unqualified intuition) and b) this cache doesn't have any time-based eviction so I wanted some mechanism to limit the number of "one-off" watches that are kept active. e.g. if a developer sends some test traffic through with a different logical path, we probably don't want to keep a watch open on that path forever. Shrinking the cache limits the number of these one-off watches. |
|
@adleong thanks, that makes sense. |
As a goal of being a transparent proxy, we want to proxy requests and responses with as little modification as possible. Basically, servers and clients should see messages that look the same whether the proxy was injected or not. With that goal in mind, we want to make sure that body headers (things like `Content-Length`, `Transfer-Encoding`, etc) are left alone. Prior to this commit, we at times were changing behavior. Sometimes `Transfer-Encoding` was added to requests, or `Content-Length: 0` may have been removed. While RC 7230 defines that differences are semantically the same, implementations may not handle them correctly. Now, we've added some fixes to prevent any of these header changes from occurring, along with tests to make sure library updates don't regress. For requests: - With no message body, `Transfer-Encoding: chunked` should no longer be added. - With `Content-Length: 0`, the header is forwarded untouched. For responses: - Tests were added that responses not allowed to have bodies (to HEAD requests, 204, 304) did not have `Transfer-Encoding` added. - Tests that `Content-Length: 0` is preserved. - Tests that HTTP/1.0 responses with no body headers do not have `Transfer-Encoding` added. - Tests that `HEAD` responses forward `Content-Length` headers (but not an actual body). Closes linkerd#447 Signed-off-by: Sean McArthur <[email protected]>
If the number of distinct paths linkerd handles is larger than the path cache, evictions will cause a lot of churn.