Method/option to limit # of subchannels created?

[Peter Hurley]

Hi,

Is there a method or option to limit the number of subchannels created to be fewer than the number of addresses resolved by ares?

Is there anything in the execution chain: ares resolver -> server address list -> address sorting -> subchannel list creation that can ultimately reduce the # of subchannels created?

Regards,

Peter Hurley

[apo...@google.com]

> Is there a method or option to limit the number of subchannels created to be fewer than the number of addresses resolved by ares?

First, are you trying to limit the number of subchannels created, or the number of connections created? (note, a subchannel data structure takes some memory of course but does not necessarily have an active TCP connection associated with it).

We don't have an option for limiting the number of subchannels. However, we do have a concept of load balancing policy (also see https://github.com/grpc/grpc/blob/master/doc/load-balancing.md#:~:text=The%20gRPC%20client%20supports%20an,and%20managing%20their%20connectivity%20behavior), which can be used as a coarse grained knob for configuring the number of active connections that a channel will have open.

Some key points:

- if you're using the pick_first load balancing policy (the default one), then the channel will try to maintain just one connection at a time, no matter how many addresses were resolved

- if you're using the round_robin policy, then the channel will try to maintain one connection to each address that was resolved

- there are other LB policies using lookaside load balancers linked to from https://github.com/grpc/grpc/blob/master/doc/load-balancing.md#:~:text=The%20gRPC%20client%20supports%20an,and%20managing%20their%20connectivity%20behavior

[Peter Hurley]

Thanks for the reply; I wanted to verify there wasn't some method that I wasn't aware of.
It's a simple enough option to add and evaluate when creating the PickFirstSubchannelList.

I'm using the pick_first load balancer since I only want one subchannel connected at any one time.

I want to limit the number of subchannels attempted by pick_first so that a channel fails to TRANSIENT_FAILURE state faster if a smaller subset of subchannels fail.

[sanjay...@google.com]

You may consider creating a custom resolver (or extend the current ares resolver) to limit the number of addresses returned.

[apo...@google.com]

There is not such an option to limit number of subchannels in pick first, currently.

Using a custom resolver as sanjaypujare@ mentioned might be an option. I will note though, the c-core resolver API is not a public API nor is it stable.

The best option here probably depends on how these connect attempts are failing i.e. why each connect attempt is taking so long that the sum is a problem.

A few things I can think of:

a) Can you limit the number of addresses in DNS records?

b) Can you tune the connection timeouts? (see options for doing this in https://github.com/grpc/grpc/blob/b29c26d6b870a71a251af930a54edc97ed0d5324/include/grpc/impl/codegen/grpc_types.h#L262)

c) If a certain set of address consistently fails to connect (e.g. IPv6 addresses or IPv4 addresses), can you, for example, configure routing tables in order to make connect attempts to those addresses fail fast?

thanks,

Alex