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

      All Methods Instance Methods Abstract Methods 
      Modifier and Type Method Description
      com.google.protobuf.DoubleValue getPerUpstreamPreconnectRatio()
      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.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.
      • 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 Detail

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