forked from scylladb/seastar
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
posix-stack: Introduce new, port based, load balancing algorithm for …
…connections New algorithm distributes connection according to peer's port address. Designated shard is determined by ip_port modulo smp. This allow client to connect to specific shard by choosing its local port carefully.
- Loading branch information
Gleb Natapov
committed
Sep 12, 2018
1 parent
426f979
commit f51eea8
Showing
5 changed files
with
72 additions
and
9 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,42 @@ | ||
# Motivation | ||
|
||
In sharded systems like seastar it is important for work to be | ||
distributed equally between all shards to achieve maximum performance | ||
from the system. Networking subsystem has its part in distributing work | ||
equally. For instance if on a server all connections will be served by | ||
single shard only, the system will be working with the speed of this | ||
one shard and all other shards will be underutilized. | ||
|
||
# Common ways to distribute work received over network between shards | ||
|
||
Two common ways to distribute work between shards are: | ||
- do the work at a shard that received it | ||
- shard that does actual work depends on a data been processed | ||
(one way to do it is to hash(data) % smp_count = shard) | ||
|
||
# Load Balancing | ||
|
||
Those two ways asks for different strategy to distribute connections | ||
between shards. The first one will work best if each cpu will have the | ||
same amount of connections (assuming each connection gets same amount of | ||
works) the second will work best if data will arrive to a shard where | ||
it is going to be processed and actual connection distribution does | ||
not matter. | ||
|
||
Seastar's posix stack supports both of those strategies. Desired | ||
one can be chosen by specifying load balancing algorithm in | ||
listen_options provided to reactor::listen() call. Available options | ||
are: | ||
|
||
- load_balancing_algorithm::connection_distribution | ||
|
||
Make sure that new connection will be placed to a shard with smallest | ||
amount of connections of the same type. | ||
|
||
- load_balancing_algorithm::port | ||
|
||
Destination shard is chosen as a function of client's local port: | ||
shard = port_number % num_shards. This allows a client to make sure that | ||
a connection will be processed by a specific shard by choosing its local | ||
port accordingly (the knowledge about amount of shards in the server is | ||
needed and can be negotiated by different channel). |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters