Nombre optimal de connexions dans le pool de connexions

Question

Nous utilisons actuellement 4 fenêtres CPU avec 8 Go de RAM et MySQL 5.x installées sur la même boîte. Nous utilisons le serveur d'applications Weblogic pour notre application. Nous ciblons 200 utilisateurs simultanés pour notre application (évidemment pas pour le même module / écran). Quel est donc le nombre optimal de connexions à configurer dans le pool de connexions (nombre minimal et maximal) (Nous utilisons le mécanisme de pooling de connexions de weblogic AS)?

Answer 1

Il existe une réponse très simple à cette question:

Le nombre de connexions dans le pool de connexions doit être égal au nombre de threads d'exécution configurés dans WebLogic .

La logique est très simple: si le nombre de connexions est inférieur au nombre de threads, une partie du thread attend peut-être une connexion, créant ainsi un goulot d'étranglement dans le pool de connexions. Ainsi, il devrait être au moins égal au nombre de threads d'exécution (taille du pool de threads).

Answer 2

Voulez-vous vraiment dire 200 utilisateurs concurrents ou seulement 200 utilisateurs connectés? Dans la plupart des cas, un utilisateur de navigateur ne sera pas en mesure de faire plus d'une demande de page par seconde. Ainsi, 200 utilisateurs se traduisent par 200 transactions par seconde. C'est un nombre assez élevé pour la plupart des applications.

Quoi qu'il en soit, à titre d'exemple, allons avec 200 transactions par seconde. Supposons que chaque terminal (navigateur) tx prenne 0,5 seconde et que, sur 0,5 seconde, 0,25 soit dépensé dans la base de données. Ainsi, vous auriez besoin de 0,5 * 200 ou de 100 connexions dans le pool thead de WebLogic et de 0,25 * 200 = 50 connexions dans le pool de connexions à la base de données.

Par mesure de sécurité, je voudrais définir une taille de pool de threads maximale supérieure d'au moins 25% à celle attendue pour les pointes de charge. Les minimums peuvent être une petite fraction du maximum, mais le compromis est que cela pourrait prendre plus de temps pour certains utilisateurs car une nouvelle connexion devrait être créée. Dans ce cas, 50 à 100 connexions ne représentent pas beaucoup pour une base de données, donc c'est probablement un bon numéro de départ.

Notez que pour déterminer les temps de réponse moyens de vos transactions, ainsi que le temps moyen de vos requêtes de base de données, vous devrez effectuer un test de performance, car vos temps de chargement ne seront probablement pas les mêmes que ceux que vous voyez. avec un seul utilisateur.

Answer 3

Le dimensionnement du pool de connexions n’est pas une mince affaire. Vous avez essentiellement besoin de:

• métriques pour étudier l'utilisation de la connexion
• mécanismes de basculement en l'absence de connexion

FlexyPool vise à vous aider à déterminer la bonne taille de pool de connexions.

Vous pouvez consulter les articles suivants:

• FlexyPool, mise en commun réactive des connexions

• Dimensionnement du pool de connexions Professional

• L'équation d'évolutivité simple

Answer 4

Vous devez définir les différents flux de travail attendus pour le savoir. Dans l’idéal, votre pool de connexions ajustera également de manière dynamique le nombre de connexions en direct en fonction de l’utilisation récente, car il est assez courant que la charge soit fonction de l’heure du jour dans votre zone géographique cible.

Commencez avec un petit nombre et essayez d'atteindre un nombre raisonnable d'utilisateurs simultanés, puis augmentez le volume. Je pense que vous constaterez probablement que votre mécanisme de mise en commun des connexions n’est pas aussi déterminant dans votre évolutivité que le reste du logiciel.

Answer 5

Le pool de connexions doit pouvoir se développer et se scinder en fonction des besoins réels. Enregistrez les numéros nécessaires pour effectuer l'analyse sur le système en cours d'exécution, soit via des instructions de journalisation, soit via la surveillance JMX. Envisagez de configurer des alertes pour des scénarios tels que "crête détectée: plus de X nouvelles entrées doivent être allouées en Y secondes", "la connexion a été hors du pool pendant plus de X secondes". ce qui vous permettra d’accorder une attention particulière aux problèmes de performances avant qu’ils ne posent de réels problèmes.

Answer 6

C’est quelque chose qui doit être testé et déterminé sur une base individuelle - il est quasiment impossible de donner une réponse précise à votre situation sans être au courant de tout cela.

Answer 7

Il est difficile d’obtenir des données fiables pour cela. Cela dépend également d'un certain nombre de facteurs que vous ne mentionnez pas -

• 200 utilisateurs simultanés, mais quelle part de leur activité va générer des requêtes de base de données? 10 requêtes par chargement de page? 1 requête juste sur la connexion? etc. etc.

• Taille des requêtes et de la base de données évidemment. Certaines requêtes s'exécutent en millisecondes, d'autres en quelques minutes.

Vous pouvez surveiller mysql pour surveiller les requêtes actives en cours avec l'option "show processlist". Cela pourrait vous donner une meilleure idée de la quantité d’activité actuellement présente dans la base de données sous une charge maximale.

Answer 8

D'après mon expérience des systèmes financiers à transaction élevée, si vous souhaitez gérer, par exemple, 1K requêtes par seconde et que vous disposez de 32 processeurs, vous devez disposer de < code> 1000/32 ouvert interroge la connexion à votre base de données.

Voici ma formule:

  

RPS / CPU_COUNT

Si la plupart des cas, votre moteur de base de données sera en mesure de traiter vos demandes, même dans des nombres beaucoup plus faibles, mais vos connexions seront en mode attente si le nombre est faible.

Je pense qu'il est assez important de mentionner que votre base de données devrait pouvoir gérer ces transactions (en fonction de la vitesse de votre disque, de la configuration de la base de données et de la puissance du serveur).

Bonne chance.