blob: 7c3d902789a714d3cbfe57a6399974f9c306c724 (
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
|
Probl�me des connexions simultan�es avec un backend
Pour chaque serveur, 3 cas possibles :
- pas de limite (par d�faut)
- limite statique (maxconn)
- limite dynamique (maxconn/(ratio de px->conn), avec minconn)
On a donc besoin d'une limite sur le proxy dans le cas de la limite
dynamique, afin de fixer un seuil et un ratio. Ce qui compte, c'est
le point apr�s lequel on passe d'un r�gime lin�aire � un r�gime
satur�.
On a donc 3 phases :
- r�gime minimal (0..srv->minconn)
- r�gime lin�aire (srv->minconn..srv->maxconn)
- r�gime satur� (srv->maxconn..)
Le minconn pourrait aussi ressortir du serveur ?
En pratique, on veut :
- un max par serveur
- un seuil global auquel les serveurs appliquent le max
- un seuil minimal en-dessous duquel le nb de conn est
maintenu. Cette limite a un sens par serveur (jamais moins de X conns)
mais aussi en global (pas la peine de faire du dynamique en dessous de
X conns � r�partir). La difficult� en global, c'est de savoir comment
on calcule le nombre min associ� � chaque serveur, vu que c'est un ratio
d�fini � partir du max.
Ca revient � peu pr�s � la m�me chose que de faire 2 �tats :
- r�gime lin�aire avec un offset (srv->minconn..srv->maxconn)
- r�gime satur� (srv->maxconn..)
Sauf que dans ce cas, le min et le max sont bien par serveur, et le seuil est
global et correspond � la limite de connexions au-del� de laquel on veut
tourner � plein r�gime sur l'ensemble des serveurs. On peut donc parler de
passage en mode "full", "saturated", "optimal". On peut �galement parler de
la fin de la partie "scalable", "dynamique".
=> fullconn 1000 par exemple ?
|
