Simulation de performance

Répartition des transactions sur plusieurs serveurs SQL depuis un serveur GridScale versus la

situation actuelle.

Évaluation de 2 scénarios

Scénario #1 : Utilisation de 3 machines en cluster avec une instance par machine. Ce scénarios est actuellement en place.

Scénario #2 : Utilisation de GridScale pour répartir la charge sur les 3 machines.

Charge normale actuel

1000EXT

500MIX

200INT

TPS

Transaction par seconde

Instances

Charge maximale

Hypothèse : maximum de 8000 TPS par machine.

NOTE : Pour être capable d’évaluer le max, il faudrait stresser les serveurs jusqu’au point de faille.

Charge normale évaluée

13%

6%

3%

Charge %

8000

8000

8000

TPS Max

1000EXT

500MIX

200INT

TPSInstances

Facteur de charge lors d’un évenement

Lorsqu’un évenement arrive, quel sera l’accroissement de la charge ?

Hypothèse : Disons que la charge sera 10 fois plus grande.

Surcharge évaluée

125%

63%

25%

Charge %

8000

8000

8000

TPS Max

10000EXT

5000MIX

2000INT

TPS x 10Instances

Le serveur en surcharge

Comme vous pouvez constater, le serveur EXT est en surcharge (125%) lors d’un évenement et les 2 autres sont capable de respirer encore.

Calculs avec la répartition de charge selon le scénario #2 Toutes les transactions sont réparties aux trois serveurs. GridScale balance les lectures sur un serveur mais transmet les

écritures sur tous les serveurs. Hypothèse : 10% des transactions sont des écritures et 90%

sont des lectures seulement. En surcharge, les serveurs ont 17000 transactions à la secondes

dont : 1700 écritures et 15300 lectures. Donc chaque serveur reçois les 1700 écritures et seulement un

tier des 15300 lectures. Donc 5100 lectures. Ce qui fait que les serveurs reçoivent tous :

1700 + 5100 = 6800 TPS Note : avec une répartition 20%, 80% = 7934 TPS

Surcharge évaluée

85%

85%

85%

Charge %

8000

8000

8000

TPS Max

6800EXT

6800MIX

6800INT

TPSInstances

Ajout de noeuds

Vu le fait que GridScale répartit la charge sur les 3 serveurs, aucun serveur n’a subit d’arrêt de service.

Si on constate que la surcharge est constante ou qu’un évenement est prévu, il est possible d’ajouter un serveur rapidement.

Voyont ce qu’il se passerait dans ce cas.

Surcharge répartie sur 4 noeuds

69%55258000EXT

69%

69%

69%

Charge %

8000

8000

8000

TPS Max

5525NEW

5525MIX

5525INT

TPSInstances

Conclusion

Le scénario #1 pourrait probablement passer l’épisode de surcharge temporaire en ajoutant de la mémoire et un CPU. Ceci permettrait d’augmenter la capacité maximal en TPS mais le problème reviendra plus tard.

L’avantage du scénario #2 est d’augmenter le contrôle lors des épisodes de surcharges.

Questions ?