blob: 2069ae913c6c47612e0b86c1d0b9f8152cd46ef0 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
# 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,
another way is to bind shards to different server addresses)
# 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).
- load_balancing_algorithm::fixed
Destination shard is statically configured in listen_options::fixed_cpu. This
allows a client to make sure that a connection to a server address will be
established in a specific shard, without any further negotiations.
|
