Interface Cluster.PreconnectPolicyOrBuilder

All Superinterfaces:
com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder
All Known Implementing Classes:
Cluster.PreconnectPolicy, Cluster.PreconnectPolicy.Builder
Enclosing class:
Cluster

public static interface Cluster.PreconnectPolicyOrBuilder extends com.google.protobuf.MessageOrBuilder
  • Method Summary

    Modifier and Type
    Method
    Description
    com.google.protobuf.DoubleValue
    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.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.

    Methods inherited from interface com.google.protobuf.MessageLiteOrBuilder

    isInitialized

    Methods inherited from interface com.google.protobuf.MessageOrBuilder

    findInitializationErrors, getAllFields, getDefaultInstanceForType, getDescriptorForType, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof
  • Method Details

    • hasPerUpstreamPreconnectRatio

      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) = { ... }
      Returns:
      Whether the perUpstreamPreconnectRatio field is set.
    • getPerUpstreamPreconnectRatio

      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) = { ... }
      Returns:
      The perUpstreamPreconnectRatio.
    • getPerUpstreamPreconnectRatioOrBuilder

      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) = { ... }
    • hasPredictivePreconnectRatio

      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) = { ... }
      Returns:
      Whether the predictivePreconnectRatio field is set.
    • getPredictivePreconnectRatio

      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) = { ... }
      Returns:
      The predictivePreconnectRatio.
    • getPredictivePreconnectRatioOrBuilder

      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) = { ... }