Class Cluster.PreconnectPolicy.Builder
java.lang.Object
com.google.protobuf.AbstractMessageLite.Builder
com.google.protobuf.AbstractMessage.Builder<Cluster.PreconnectPolicy.Builder>
com.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>
io.envoyproxy.envoy.config.cluster.v3.Cluster.PreconnectPolicy.Builder
- All Implemented Interfaces:
com.google.protobuf.Message.Builder
,com.google.protobuf.MessageLite.Builder
,com.google.protobuf.MessageLiteOrBuilder
,com.google.protobuf.MessageOrBuilder
,Cluster.PreconnectPolicyOrBuilder
,Cloneable
- Enclosing class:
Cluster.PreconnectPolicy
public static final class Cluster.PreconnectPolicy.Builder
extends com.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>
implements Cluster.PreconnectPolicyOrBuilder
Protobuf type
envoy.config.cluster.v3.Cluster.PreconnectPolicy
-
Field Summary
FieldsModifier and TypeFieldDescriptionprivate int
private com.google.protobuf.DoubleValue
private com.google.protobuf.SingleFieldBuilder
<com.google.protobuf.DoubleValue, com.google.protobuf.DoubleValue.Builder, com.google.protobuf.DoubleValueOrBuilder> private com.google.protobuf.DoubleValue
private com.google.protobuf.SingleFieldBuilder
<com.google.protobuf.DoubleValue, com.google.protobuf.DoubleValue.Builder, com.google.protobuf.DoubleValueOrBuilder> -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionbuild()
private void
clear()
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.static final com.google.protobuf.Descriptors.Descriptor
com.google.protobuf.Descriptors.Descriptor
com.google.protobuf.DoubleValue
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.com.google.protobuf.DoubleValue.Builder
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.com.google.protobuf.DoubleValueOrBuilder
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.com.google.protobuf.DoubleValue
Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.com.google.protobuf.DoubleValue.Builder
Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.com.google.protobuf.DoubleValueOrBuilder
Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.boolean
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.boolean
Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.protected com.google.protobuf.GeneratedMessage.FieldAccessorTable
private com.google.protobuf.SingleFieldBuilder
<com.google.protobuf.DoubleValue, com.google.protobuf.DoubleValue.Builder, com.google.protobuf.DoubleValueOrBuilder> Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.private com.google.protobuf.SingleFieldBuilder
<com.google.protobuf.DoubleValue, com.google.protobuf.DoubleValue.Builder, com.google.protobuf.DoubleValueOrBuilder> Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.final boolean
private void
mergeFrom
(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry) mergeFrom
(com.google.protobuf.Message other) mergePerUpstreamPreconnectRatio
(com.google.protobuf.DoubleValue value) Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.mergePredictivePreconnectRatio
(com.google.protobuf.DoubleValue value) Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.setPerUpstreamPreconnectRatio
(com.google.protobuf.DoubleValue value) Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.setPerUpstreamPreconnectRatio
(com.google.protobuf.DoubleValue.Builder builderForValue) Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.setPredictivePreconnectRatio
(com.google.protobuf.DoubleValue value) Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.setPredictivePreconnectRatio
(com.google.protobuf.DoubleValue.Builder builderForValue) Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.Methods inherited from class com.google.protobuf.GeneratedMessage.Builder
addRepeatedField, clearField, clearOneof, clone, getAllFields, getField, getFieldBuilder, getOneofFieldDescriptor, getParentForChildren, getRepeatedField, getRepeatedFieldBuilder, getRepeatedFieldCount, getUnknownFields, getUnknownFieldSetBuilder, hasField, hasOneof, internalGetMapField, internalGetMapFieldReflection, internalGetMutableMapField, internalGetMutableMapFieldReflection, isClean, markClean, mergeUnknownFields, mergeUnknownLengthDelimitedField, mergeUnknownVarintField, newBuilderForField, onBuilt, onChanged, parseUnknownField, setField, setRepeatedField, setUnknownFields, setUnknownFieldSetBuilder, setUnknownFieldsProto3
Methods inherited from class com.google.protobuf.AbstractMessage.Builder
findInitializationErrors, getInitializationErrorString, internalMergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, mergeFrom, newUninitializedMessageException, toString
Methods inherited from class com.google.protobuf.AbstractMessageLite.Builder
addAll, addAll, mergeDelimitedFrom, mergeDelimitedFrom, mergeFrom, newUninitializedMessageException
Methods inherited from class java.lang.Object
equals, finalize, getClass, hashCode, notify, notifyAll, wait, wait, wait
Methods inherited from interface com.google.protobuf.Message.Builder
mergeDelimitedFrom, mergeDelimitedFrom
Methods inherited from interface com.google.protobuf.MessageLite.Builder
mergeFrom
Methods inherited from interface com.google.protobuf.MessageOrBuilder
findInitializationErrors, getAllFields, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof
-
Field Details
-
bitField0_
private int bitField0_ -
perUpstreamPreconnectRatio_
private com.google.protobuf.DoubleValue perUpstreamPreconnectRatio_ -
perUpstreamPreconnectRatioBuilder_
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder, perUpstreamPreconnectRatioBuilder_com.google.protobuf.DoubleValueOrBuilder> -
predictivePreconnectRatio_
private com.google.protobuf.DoubleValue predictivePreconnectRatio_ -
predictivePreconnectRatioBuilder_
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder, predictivePreconnectRatioBuilder_com.google.protobuf.DoubleValueOrBuilder>
-
-
Constructor Details
-
Builder
private Builder() -
Builder
private Builder(com.google.protobuf.AbstractMessage.BuilderParent parent)
-
-
Method Details
-
getDescriptor
public static final com.google.protobuf.Descriptors.Descriptor getDescriptor() -
internalGetFieldAccessorTable
protected com.google.protobuf.GeneratedMessage.FieldAccessorTable internalGetFieldAccessorTable()- Specified by:
internalGetFieldAccessorTable
in classcom.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>
-
maybeForceBuilderInitialization
private void maybeForceBuilderInitialization() -
clear
- Specified by:
clear
in interfacecom.google.protobuf.Message.Builder
- Specified by:
clear
in interfacecom.google.protobuf.MessageLite.Builder
- Overrides:
clear
in classcom.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>
-
getDescriptorForType
public com.google.protobuf.Descriptors.Descriptor getDescriptorForType()- Specified by:
getDescriptorForType
in interfacecom.google.protobuf.Message.Builder
- Specified by:
getDescriptorForType
in interfacecom.google.protobuf.MessageOrBuilder
- Overrides:
getDescriptorForType
in classcom.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>
-
getDefaultInstanceForType
- Specified by:
getDefaultInstanceForType
in interfacecom.google.protobuf.MessageLiteOrBuilder
- Specified by:
getDefaultInstanceForType
in interfacecom.google.protobuf.MessageOrBuilder
-
build
- Specified by:
build
in interfacecom.google.protobuf.Message.Builder
- Specified by:
build
in interfacecom.google.protobuf.MessageLite.Builder
-
buildPartial
- Specified by:
buildPartial
in interfacecom.google.protobuf.Message.Builder
- Specified by:
buildPartial
in interfacecom.google.protobuf.MessageLite.Builder
-
buildPartial0
-
mergeFrom
- Specified by:
mergeFrom
in interfacecom.google.protobuf.Message.Builder
- Overrides:
mergeFrom
in classcom.google.protobuf.AbstractMessage.Builder<Cluster.PreconnectPolicy.Builder>
-
mergeFrom
-
isInitialized
public final boolean isInitialized()- Specified by:
isInitialized
in interfacecom.google.protobuf.MessageLiteOrBuilder
- Overrides:
isInitialized
in classcom.google.protobuf.GeneratedMessage.Builder<Cluster.PreconnectPolicy.Builder>
-
mergeFrom
public Cluster.PreconnectPolicy.Builder mergeFrom(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry) throws IOException - Specified by:
mergeFrom
in interfacecom.google.protobuf.Message.Builder
- Specified by:
mergeFrom
in interfacecom.google.protobuf.MessageLite.Builder
- Overrides:
mergeFrom
in classcom.google.protobuf.AbstractMessage.Builder<Cluster.PreconnectPolicy.Builder>
- Throws:
IOException
-
hasPerUpstreamPreconnectRatio
public boolean hasPerUpstreamPreconnectRatio()Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
- Specified by:
hasPerUpstreamPreconnectRatio
in interfaceCluster.PreconnectPolicyOrBuilder
- Returns:
- Whether the perUpstreamPreconnectRatio field is set.
-
getPerUpstreamPreconnectRatio
public com.google.protobuf.DoubleValue getPerUpstreamPreconnectRatio()Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
- Specified by:
getPerUpstreamPreconnectRatio
in interfaceCluster.PreconnectPolicyOrBuilder
- Returns:
- The perUpstreamPreconnectRatio.
-
setPerUpstreamPreconnectRatio
public Cluster.PreconnectPolicy.Builder setPerUpstreamPreconnectRatio(com.google.protobuf.DoubleValue value) Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
-
setPerUpstreamPreconnectRatio
public Cluster.PreconnectPolicy.Builder setPerUpstreamPreconnectRatio(com.google.protobuf.DoubleValue.Builder builderForValue) Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
-
mergePerUpstreamPreconnectRatio
public Cluster.PreconnectPolicy.Builder mergePerUpstreamPreconnectRatio(com.google.protobuf.DoubleValue value) Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
-
clearPerUpstreamPreconnectRatio
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
-
getPerUpstreamPreconnectRatioBuilder
public com.google.protobuf.DoubleValue.Builder getPerUpstreamPreconnectRatioBuilder()Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
-
getPerUpstreamPreconnectRatioOrBuilder
public com.google.protobuf.DoubleValueOrBuilder getPerUpstreamPreconnectRatioOrBuilder()Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
- Specified by:
getPerUpstreamPreconnectRatioOrBuilder
in interfaceCluster.PreconnectPolicyOrBuilder
-
internalGetPerUpstreamPreconnectRatioFieldBuilder
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder, internalGetPerUpstreamPreconnectRatioFieldBuilder()com.google.protobuf.DoubleValueOrBuilder> Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream. This is useful for high-QPS or latency-sensitive services. Preconnecting will only be done if the upstream is healthy and the cluster has traffic. For example if this is 2, for an incoming HTTP/1.1 stream, 2 connections will be established, one for the new incoming stream, and one for a presumed follow-up stream. For HTTP/2, only one connection would be established by default as one connection can serve both the original and presumed follow-up stream. In steady state for non-multiplexed connections a value of 1.5 would mean if there were 100 active streams, there would be 100 connections in use, and 50 connections preconnected. This might be a useful value for something like short lived single-use connections, for example proxying HTTP/1.1 if keep-alive were false and each stream resulted in connection termination. It would likely be overkill for long lived connections, such as TCP proxying SMTP or regular HTTP/1.1 with keep-alive. For long lived traffic, a value of 1.05 would be more reasonable, where for every 100 connections, 5 preconnected connections would be in the queue in case of unexpected disconnects where the connection could not be reused. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight. This means in steady state if a connection is torn down, a subsequent streams will pay an upstream-rtt latency penalty waiting for a new connection. This is limited somewhat arbitrarily to 3 because preconnecting too aggressively can harm latency more than the preconnecting helps.
.google.protobuf.DoubleValue per_upstream_preconnect_ratio = 1 [(.validate.rules) = { ... }
-
hasPredictivePreconnectRatio
public boolean hasPredictivePreconnectRatio()Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
- Specified by:
hasPredictivePreconnectRatio
in interfaceCluster.PreconnectPolicyOrBuilder
- Returns:
- Whether the predictivePreconnectRatio field is set.
-
getPredictivePreconnectRatio
public com.google.protobuf.DoubleValue getPredictivePreconnectRatio()Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
- Specified by:
getPredictivePreconnectRatio
in interfaceCluster.PreconnectPolicyOrBuilder
- Returns:
- The predictivePreconnectRatio.
-
setPredictivePreconnectRatio
public Cluster.PreconnectPolicy.Builder setPredictivePreconnectRatio(com.google.protobuf.DoubleValue value) Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
-
setPredictivePreconnectRatio
public Cluster.PreconnectPolicy.Builder setPredictivePreconnectRatio(com.google.protobuf.DoubleValue.Builder builderForValue) Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
-
mergePredictivePreconnectRatio
public Cluster.PreconnectPolicy.Builder mergePredictivePreconnectRatio(com.google.protobuf.DoubleValue value) Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
-
clearPredictivePreconnectRatio
Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
-
getPredictivePreconnectRatioBuilder
public com.google.protobuf.DoubleValue.Builder getPredictivePreconnectRatioBuilder()Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
-
getPredictivePreconnectRatioOrBuilder
public com.google.protobuf.DoubleValueOrBuilder getPredictivePreconnectRatioOrBuilder()Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
- Specified by:
getPredictivePreconnectRatioOrBuilder
in interfaceCluster.PreconnectPolicyOrBuilder
-
internalGetPredictivePreconnectRatioFieldBuilder
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder, internalGetPredictivePreconnectRatioFieldBuilder()com.google.protobuf.DoubleValueOrBuilder> Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services. This is currently supported for a subset of deterministic non-hash-based load-balancing algorithms (weighted round robin, random). Unlike ``per_upstream_preconnect_ratio`` this preconnects across the upstream instances in a cluster, doing best effort predictions of what upstream would be picked next and pre-establishing a connection. Preconnecting will be limited to one preconnect per configured upstream in the cluster and will only be done if there are healthy upstreams and the cluster has traffic. For example if preconnecting is set to 2 for a round robin HTTP/2 cluster, on the first incoming stream, 2 connections will be preconnected - one to the first upstream for this cluster, one to the second on the assumption there will be a follow-up stream. If this value is not set, or set explicitly to one, Envoy will fetch as many connections as needed to serve streams in flight, so during warm up and in steady state if a connection is closed (and per_upstream_preconnect_ratio is not set), there will be a latency hit for connection establishment. If both this and preconnect_ratio are set, Envoy will make sure both predicted needs are met, basically preconnecting max(predictive-preconnect, per-upstream-preconnect), for each upstream.
.google.protobuf.DoubleValue predictive_preconnect_ratio = 2 [(.validate.rules) = { ... }
-