Numero ottimale di connessioni nel pool di connessioni

Question

Attualmente stiamo usando una finestra di Windows da 4 cpu con 8 GB di RAM con MySQL 5.x installato sulla stessa scatola. Stiamo usando il server delle applicazioni Weblogic per la nostra applicazione. Puntiamo a 200 utenti simultanei per la nostra applicazione (ovviamente non per lo stesso modulo / schermo). Quindi qual è il numero ottimale di connessioni che dovremmo configurare nel pool di connessioni (numero minimo e massimo) (stiamo usando il meccanismo di pooling delle connessioni di weblog AS)?

Answer 1

C'è una risposta molto semplice a questa domanda:

Il numero di connessioni nel pool di connessioni dovrebbe essere uguale al numero dei thread exec configurati in WebLogic .

La logica è molto semplice: se il numero delle connessioni è inferiore al numero di thread, alcuni thread potrebbero attendere una connessione, rendendo così il pool di connessioni un collo di bottiglia. Quindi, dovrebbe essere uguale almeno al numero dei thread exec (dimensione del pool di thread).

Answer 2

Intendevi davvero 200 utenti simultanei o solo 200 utenti registrati? Nella maggior parte dei casi, un utente del browser non sarà in grado di fare più di 1 richiesta di pagina al secondo. Quindi, 200 utenti si traducono in 200 transazioni al secondo. Questo è un numero piuttosto elevato per la maggior parte delle applicazioni.

Indipendentemente da ciò, ad esempio, andiamo con 200 transazioni al secondo. Supponiamo che ogni front-end (browser) tx richieda 0,5 secondi per essere completato e degli 0,5 secondi, 0,25 vengono spesi nel database. Pertanto, occorrerebbero 0,5 * 200 o 100 connessioni nel pool di thead WebLogic e 0,25 * 200 = 50 connessioni nel pool di connessioni DB.

Per sicurezza, impostarei le dimensioni massime del pool di thread su almeno il 25% in più di quanto ti aspetti da consentire picchi di carico. I minimi possono essere una piccola frazione del massimo, ma il compromesso è che potrebbe richiedere più tempo per alcuni utenti perché dovrebbe essere creata una nuova connessione. In questo caso, 50-100 connessioni non sono così tante per un DB, quindi è probabilmente un buon numero iniziale.

Si noti che per capire quali sono i tempi medi di risposta alla transazione, insieme al tempo medio di interrogazione del DB, è necessario eseguire un test delle prestazioni perché i tempi a carico probabilmente non saranno quelli che vengono visualizzati con un singolo utente.

Answer 3

Il dimensionamento del pool di connessioni non è cosa da poco. Fondamentalmente hai bisogno di:

• metriche per esaminare l'utilizzo della connessione
• meccanismi di failover per quando non è disponibile alcuna connessione

FlexyPool ha lo scopo di aiutarti a capire quale sia la dimensione giusta del nostro pool di connessioni.

Puoi controllare i seguenti articoli:

• FlexyPool, pooling di connessioni reattive

• Dimensionamento pool di connessioni professionali

• La semplice equazione di scalabilità

Answer 4

Dovresti profilare i diversi flussi di lavoro previsti per scoprirlo. Idealmente, il pool di connessioni regolerà anche in modo dinamico il numero di connessioni live in base all'utilizzo recente, poiché è abbastanza comune che il carico sia una funzione dell'ora del giorno corrente nell'area geografica di destinazione.

Inizia con un piccolo numero e prova a raggiungere un numero ragionevole di utenti simultanei, quindi avvialo. Penso che sia probabile che scoprirai che il tuo meccanismo di pool di connessioni non è altrettanto determinante nella tua scalabilità come il resto del software.

Answer 5

Il pool di connessioni dovrebbe essere in grado di crescere e cambiare in base alle esigenze effettive. Registra i numeri necessari per eseguire analisi sul sistema in esecuzione, attraverso le dichiarazioni di registrazione o attraverso la sorveglianza JMX. Prendi in considerazione la possibilità di impostare avvisi per scenari come "picco rilevato: più di X nuove voci devono essere allocate in Y secondi", "la connessione è stata fuori dal pool per più di X secondi" che ti consentirà di prestare attenzione ai problemi di prestazioni prima che si verifichino problemi reali.

Answer 6

Questo è qualcosa che deve essere testato e determinato su base individuale - è praticamente impossibile dare una risposta accurata per le tue circostanze senza conoscerle intimamente.

Answer 7

È difficile ottenere dati concreti per questo. Dipende anche da una serie di fattori che non menzioni -

• 200 utenti simultanei, ma quanta parte della loro attività genererà query sul database? 10 query per caricamento pagina? 1 query solo al login? ecc. ecc.

• Dimensioni delle query e db ovviamente. Alcune query vengono eseguite in millisecondi, altre in pochi minuti.

Puoi monitorare mysql per guardare le query attive correnti con " process processlist " ;. Questo potrebbe darti un'idea più precisa di quanta attività sta effettivamente svolgendo nel db sotto carico di picco.

Answer 8

In base alla mia esperienza con sistemi finanziari con transazioni elevate, se vuoi gestire, ad esempio, 1K richieste al secondo e disponi di CPU 32 , devi avere < code> 1000/32 apre sondaggi di connessione al tuo database.

Ecco la mia formula:

  

RPS / CPU_COUNT

Se la maggior parte dei casi, il tuo motore di database sarà in grado di gestire le tue richieste anche in numeri molto più bassi, ma le tue connessioni saranno in modalità di attesa se il numero è basso.

Penso che sia abbastanza importante menzionare che il tuo database dovrebbe essere in grado di gestire tali transazioni (in base alla velocità del tuo disco, alla configurazione del database e alla potenza del server).

Buona fortuna.