Currently, the maglev hash algorithm default to table size to 65537.
It is the recommended size by a paper but it is better if the user
can set this value.
This patch introduces a new MaglevLbConfig that contains table
size of maglev.
So, now, the user can set the table size of maglev by their situation.
Signed-off-by: DongRyeol Cha <dr83.cha@samsung.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5fd73ca889aa12618c626c96bb33fde4707f8bf0
This can be used in similar situations to maglev/ring, but can be used when the host selection must remain the same for existing sessions even if more hosts are added to the cluster.
In a test with 1500 endpoints, updating 50 (remove 50, add 50 different ones) took:
without new setting: ~500ms
with new setting (this PR): ~4ms
Signed-off-by: Greg Greenway <ggreenway@apple.com>
Mirrored from https://github.com/envoyproxy/envoy @ 724df08c329c8270509e2a8568be90fd43d597c1
This is as described in the paper https://arxiv.org/abs/1608.01350; Logic followed is similar to what's in haproxy.
Signed-off-by: Santosh Cheler <santosh.cheler@appdynamics.com>
Mirrored from https://github.com/envoyproxy/envoy @ 760a164640acf75a8009ac89b5ff06f78a733221
Add connect_pool_per_downstream_connection flag to the cluster config (disabled by default)
Add a hashKey method to Connection in order to be able to hash on the connection ID
Signed-off-by: Craig Radcliffe <craig.radcliffe@broadcom.com>
Mirrored from https://github.com/envoyproxy/envoy @ 76a1b24dd511bb5b3a38da3e84c9003ccadc64ce
Implementing per-upstream prefetching, useful for high QPS or latency-sensitive services.
Risk Level: low (off by default)
Testing: new unit tests, integration test
Docs Changes: n/a
Release Notes: not yet
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ f6e90f2966887b25a8b6d5dd7f13ffb32865d66b
Created a new struct for optional cluster stats. Moved timeout budget stats and added request response headers and body stats in the new struct.
Risk Level: Low
Testing: Added test cases
Docs Changes: added
Release Notes: added
Fixes#10308 , Fixes#3621
Signed-off-by: Ranjith Kumar <ranjith.dakshana2015@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ a24c95e4fe035ae5d05691ee2b2bd7011093a9e9
* Add support for making Least Requests LB behave like Round Robin in weighted hosts case
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Address feedback
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Perf/logging improvements
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Address feedback and cleanup BUILD file
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Make active requests exponent configurable via CDS/runtime
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Address feedback
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Validate log message
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Update cluster memory test golden values
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Fix method name
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Explicitly initialize active_request_bias_
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Try to make clang-tidy happy
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Use unique_ptr instead of optional
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Update stats integration test
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Check whether memory footprint is reduced without LB changes
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Use plain double for active request bias
Use a plain double instead of a runtime double to store the per-cluster
active request bias.
Note: The goal of this commit is to evaluate the memory overhead of this
approach. A commit with te Least Requests LB changes might follow if we
deem the memory overhead of this approach acceptable.
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Revert back to approved implementation using RuntimeDouble
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Add extra fields to CDS cluster proto to check memory usage
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Revert "Add extra fields to CDS cluster proto to check memory usage"
This reverts commit a6a285dcee9e0fe618286d3dfbfab98c957dd9c7.
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
* Add changelog entry
Signed-off-by: Gastón Kleiman <gkleiman@lyft.com>
Mirrored from https://github.com/envoyproxy/envoy @ 9f7d44850310999ecbd0cfbe8fadb70db6f258f9
These are currently set as [#not-implemented-hide:]. There should be enough plumbing here to start
implementing the first roadmap steps in #11264, i.e. some simple delta discovery flows with core
LDS/CDS/RDS/EDS/SDS.
I've punted on VHDS and SRDS until later, as these will require special case mapping of their
resource keys into context parameters.
Risk level: Low (Unused API changes).
Testing: Built docs and proto_format.sh.
Part of #11264.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 99471fd8f4ef7406f50cf41cf1cfa22bbdfeacc7
Mainly moving code, but finishes up the series of pluggable upstream PRs.
Additional Description: This unhides the configurable extension point to the cluster for selecting a connection pool and creating an upstream, which can be used for custom business logic in upstream creation.
Risk Level: medium (router refactor)
Testing: with prior PRs
Docs Changes: inline with APIs
Release Notes: added
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ 8a9d6155601846d2d256defd09a3c408c6eb4386
split out from #11327
There's a bit of transitive ugliness: declaring the extensions requires security posture, requires stub build files, requires codeowners before the code move, but it'll be pretty short lived.
Risk Level: Low (mostly only APIs)
Testing: n/a
Docs Changes: some of the new docs
Release Notes: n/a
Signed-off-by: Alyssa Wilk <alyssar@chromium.org>
Mirrored from https://github.com/envoyproxy/envoy @ e8dc25ecec277c0b94d02151de79353a9ba07b4e
Fixes a mismatch in metadata attribute name used by transport_socket_matches
Risk Level: Low
Testing: Manual review
Docs Changes: Not applicable
Fixes#10660
Signed-off-by: Raghavendra Balgi <rkbalgi@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ cb08d542389d455069f83f20dc543176ffb484fb
Users can specify metadata in a health check's config that will be
used to select a matching transport socket from those configured in a
cluster's transport_socket_matches. This allows users to configure a
different transport socket for health check connections than the one
that is used to create a connection to an endpoint for proxying.
Risk Level: low; small optional feature
Testing: added unit tests
Docs Changes: updated health check and cluster proto docs with an explanation and example.
Release Notes: added
Fixes#10575
Signed-off-by: Spencer Lewis <slewis@squareup.com>
Mirrored from https://github.com/envoyproxy/envoy @ b6c8bb3a4ac6bcce221643a4924befd5eefd6815
This patch performs a major version freeze and bump by modifying
package_version_status, using the tooling developed in #10636.
Specifically:
v2 APIs are frozen (except for where they are the latest in their
package history and still active)
v3 APIs are transitioned to be active
Candidate v4alpha APIs are generated (not used by Envoy yet)
Fixes#10355
Risk level: medium (entire API's files are modified, visually verified
to ensure things look sane, all tests pass)
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 549164c42cae84b59154ca4c36009e408aa10b52
Part of https://github.com/envoyproxy/envoy/issues/10355, this patch introduces additional
annotations to the API to support automatic inference (and developer documentation) of where the
active developer editable version of a file is, and which files are frozen or machine generated.
Risk level: Low (API annotations only)
Testing: CI
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 4c5f4310bb8a19a38e5377d7a2d2dc6aa4560f47
Modifies the well-known-names of the built-in http filters
to use the same names as the extension build system.
Handles transition of per-filter-configs.
Risk Level: low, previous name is still accepted
Testing: existing tests + deprecated tests for old names
Docs Changes: updated names
Release Notes: updated
Deprecated: old names are logged as deprecated
Signed-off-by: Stephan Zuercher <zuercher@gmail.com>
Mirrored from https://github.com/envoyproxy/envoy @ c5c1e5bb6570f81f30dd48d8b379392c84e81fe0
This PR introduces a parallel v3 API reference documentation tree to the
existing v2 one.
The docs/root/api-v3/ tree was copied from docs/root/api-v2 and the
necessary package path fixups were made manually. As a result, the tree
largely resembles the v2 docs. Long term this is likely to evolve to
reflect the shape of the new extensions tree.
The message type, field and enum anchors are sed'ed to be distinct and
self-consistent inside api-v3/.
There were a number of API proto changes that were made to obtain a
successful Sphinx build:
* References to deprecated fields were replaced by references to the replacement field.
* clang-format line wrapping in protoxform was removed, this breaks RST in some v3 protos.
* Some packages (type/metadata/v2, data/cluster/v2alpha) were force upgraded to v3, to deal with references to types that are distinct in v2/v3. This is OK as these packages probably make sense to bump for v3, in general we're going to have to think about how to do this more
cleanly, supporting dual v2/v3 references alongside each other.
* Some evil hacks for field renaming added to migrate.py for RouteAction.
There's also some additional machinery added to compute distinct v3/v3
build targets to point protodoc at.
Risk level: Low
Testing: Docs build, manual inspection.
Fixes#8087
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ ac88316892cd47b6a9b58e3736e20e8863cd0d27
In which we convert every v3alpha reference to v3. In future revs of the
stable API versioning policy, we will develop better tooling to support
> 2 alpha and stable versions. For v3, it seems reasonable to just mv
v3alpha to v3, since there should be no external consumers yet.
Risk level: Low
Testing: bazel test //test/..., CI.
Signed-off-by: Harvey Tuch <htuch@google.com>
Mirrored from https://github.com/envoyproxy/envoy @ 5248a4fb7d4c2a3d1fa151f944d3a63f6b7a06cf