Class Cluster.PreconnectPolicy.Builder
- java.lang.Object
-
- com.google.protobuf.AbstractMessageLite.Builder
-
- com.google.protobuf.AbstractMessage.Builder<BuilderT>
-
- 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
,java.lang.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 typeenvoy.config.cluster.v3.Cluster.PreconnectPolicy
-
-
Field Summary
Fields Modifier and Type Field Description private int
bitField0_
private com.google.protobuf.DoubleValue
perUpstreamPreconnectRatio_
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder,com.google.protobuf.DoubleValueOrBuilder>
perUpstreamPreconnectRatioBuilder_
private com.google.protobuf.DoubleValue
predictivePreconnectRatio_
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder,com.google.protobuf.DoubleValueOrBuilder>
predictivePreconnectRatioBuilder_
-
Method Summary
All Methods Static Methods Instance Methods Concrete Methods Modifier and Type Method Description Cluster.PreconnectPolicy
build()
Cluster.PreconnectPolicy
buildPartial()
private void
buildPartial0(Cluster.PreconnectPolicy result)
Cluster.PreconnectPolicy.Builder
clear()
Cluster.PreconnectPolicy.Builder
clearPerUpstreamPreconnectRatio()
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.Cluster.PreconnectPolicy.Builder
clearPredictivePreconnectRatio()
Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.Cluster.PreconnectPolicy
getDefaultInstanceForType()
static com.google.protobuf.Descriptors.Descriptor
getDescriptor()
com.google.protobuf.Descriptors.Descriptor
getDescriptorForType()
com.google.protobuf.DoubleValue
getPerUpstreamPreconnectRatio()
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.com.google.protobuf.DoubleValue.Builder
getPerUpstreamPreconnectRatioBuilder()
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>
getPerUpstreamPreconnectRatioFieldBuilder()
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.com.google.protobuf.DoubleValueOrBuilder
getPerUpstreamPreconnectRatioOrBuilder()
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.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.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.private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder,com.google.protobuf.DoubleValueOrBuilder>
getPredictivePreconnectRatioFieldBuilder()
Indicates how many streams (rounded up) can be anticipated across a cluster for each stream, useful for low QPS services.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.boolean
hasPerUpstreamPreconnectRatio()
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.boolean
hasPredictivePreconnectRatio()
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
internalGetFieldAccessorTable()
boolean
isInitialized()
private void
maybeForceBuilderInitialization()
Cluster.PreconnectPolicy.Builder
mergeFrom(com.google.protobuf.CodedInputStream input, com.google.protobuf.ExtensionRegistryLite extensionRegistry)
Cluster.PreconnectPolicy.Builder
mergeFrom(com.google.protobuf.Message other)
Cluster.PreconnectPolicy.Builder
mergeFrom(Cluster.PreconnectPolicy other)
Cluster.PreconnectPolicy.Builder
mergePerUpstreamPreconnectRatio(com.google.protobuf.DoubleValue value)
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.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.Cluster.PreconnectPolicy.Builder
setPerUpstreamPreconnectRatio(com.google.protobuf.DoubleValue value)
Indicates how many streams (rounded up) can be anticipated per-upstream for each incoming stream.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.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.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.-
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
-
-
-
-
Field Detail
-
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,com.google.protobuf.DoubleValueOrBuilder> perUpstreamPreconnectRatioBuilder_
-
predictivePreconnectRatio_
private com.google.protobuf.DoubleValue predictivePreconnectRatio_
-
predictivePreconnectRatioBuilder_
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder,com.google.protobuf.DoubleValueOrBuilder> predictivePreconnectRatioBuilder_
-
-
Method Detail
-
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
public Cluster.PreconnectPolicy.Builder 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
public Cluster.PreconnectPolicy getDefaultInstanceForType()
- Specified by:
getDefaultInstanceForType
in interfacecom.google.protobuf.MessageLiteOrBuilder
- Specified by:
getDefaultInstanceForType
in interfacecom.google.protobuf.MessageOrBuilder
-
build
public Cluster.PreconnectPolicy build()
- Specified by:
build
in interfacecom.google.protobuf.Message.Builder
- Specified by:
build
in interfacecom.google.protobuf.MessageLite.Builder
-
buildPartial
public Cluster.PreconnectPolicy buildPartial()
- Specified by:
buildPartial
in interfacecom.google.protobuf.Message.Builder
- Specified by:
buildPartial
in interfacecom.google.protobuf.MessageLite.Builder
-
buildPartial0
private void buildPartial0(Cluster.PreconnectPolicy result)
-
mergeFrom
public Cluster.PreconnectPolicy.Builder mergeFrom(com.google.protobuf.Message other)
- Specified by:
mergeFrom
in interfacecom.google.protobuf.Message.Builder
- Overrides:
mergeFrom
in classcom.google.protobuf.AbstractMessage.Builder<Cluster.PreconnectPolicy.Builder>
-
mergeFrom
public Cluster.PreconnectPolicy.Builder mergeFrom(Cluster.PreconnectPolicy other)
-
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 java.io.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:
java.io.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
public Cluster.PreconnectPolicy.Builder 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
-
getPerUpstreamPreconnectRatioFieldBuilder
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder,com.google.protobuf.DoubleValueOrBuilder> getPerUpstreamPreconnectRatioFieldBuilder()
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
public Cluster.PreconnectPolicy.Builder 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
-
getPredictivePreconnectRatioFieldBuilder
private com.google.protobuf.SingleFieldBuilder<com.google.protobuf.DoubleValue,com.google.protobuf.DoubleValue.Builder,com.google.protobuf.DoubleValueOrBuilder> getPredictivePreconnectRatioFieldBuilder()
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) = { ... }
-
-