Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Intelligent client connection load balancing #2978

Open
rymarm opened this issue Feb 17, 2025 · 2 comments
Open

Intelligent client connection load balancing #2978

rymarm opened this issue Feb 17, 2025 · 2 comments
Assignees

Comments

@rymarm
Copy link
Member

rymarm commented Feb 17, 2025

One drillbit may end up with significantly more client connections than others.

Here is an example of such a case:
Image

The chart shows that the highest number of connections per node is 21, while the lowest is only 3 – a difference of 7 times.

Even though query execution considers the load on all Drillbits and distributes execution accordingly, overutilizing a single Drillbit for client connections can lead to issues such as heap memory exhaustion and excessive network bandwidth usage when returning query results to the client.

The current client implementation retrieves a list of active Drillbits from Zookeeper, randomly shuffles them:

java.util.Collections.shuffle(endpoints);

and attempts to connect to the first N nodes until a connection is successful. This approach was introduced as a simple way to prevent all clients from connecting to the same Drillbit: https://issues.apache.org/jira/browse/DRILL-2512. However, it does not fully solve the problem, as one node may still end up with significantly more connections than others.

Solution
Every drillbit stores the his current number of client connections in Zookeeper. After retrieving a list of active drillbits, the client calculates the average number of connections and reorders the list based on whether a drillbit's connection count is above or below the average before attempting a connection.

The key questions I see here are:

  • Is it appropriate to store information about the current number of user connections in Zookeeper?
  • Should client connection load balancing be enabled be configurable and enabled by default?
  • Is it beneficial to distribute all connections evenly across the entire Drill cluster?
@rymarm
Copy link
Member Author

rymarm commented Feb 17, 2025

@jnturton @cgivre Hi! What do you think about the idea of balancing client connections more evenly across the Drill cluster? Do you think it could improve overall performance, or could it introduce other challenges? I'd love to hear your thoughts and opinions on how this might play out.

@cgivre
Copy link
Contributor

cgivre commented Feb 28, 2025

@rymarm I think it is an interesting idea. I have a feeling it would be harder than it may seem. The big question I have is how do you plan to get the metadata needed? Does Zookeeper do any of this? What strategy would you use for distributing queries across nodes?

For instance, let's say you have a lot of short running queries. Would it matter if they are all going to a single Drill node? Also are we thinking about data locality? Meaning is Drill sending the query to the node closest to the data?

This is an area of Drill that I don't know very much about, but these are my stream of consciousness thoughts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants