Ottima domanda. Ho usato per lottare con questa domanda. La risposta più comune su StackOverflow è "Dipende..." praticamente per ogni problema. Odio dirlo, ma in nessun luogo è più rilevante che modificare il pool di connessioni. È davvero un gioco di domanda e offerta, in cui le tue richieste di connessione sono la domanda e l'offerta è il numero di connessioni che MySQL ha a disposizione. Dipende davvero dal fatto che la tua preoccupazione principale sia impedire la restituzione di connessioni obsolete dal pool o se la tua preoccupazione è garantire che MySQL non venga sovraccaricato di connessioni inattive perché non le stai uccidendo abbastanza velocemente. La maggior parte delle persone giacciono nel mezzo da qualche parte.
Se capisci davvero perché qualcuno dovrebbe scegliere una configurazione di pool di connessioni, credimi, smetterai di cercare l'impostazione "Rocket Solid" perché saprai che è come cercare su Google un piano aziendale per il tuo negozio; È interamente radicato nel numero di richieste di connessione che ricevi e in quante connessioni persistenti sei disposto a rendere disponibili. Di seguito fornisco esempi del motivo per cui dovresti utilizzare determinate impostazioni. Mi riferisco a variabili che dovrai modificare all'interno del tag "Resource" del tag "Context" del tuo file Context.xml. Un esempio di configurazione completa può essere visto in fondo.
Basso traffico
In questa situazione hai poche richieste alla tua applicazione, quindi ci sono buone probabilità che TUTTE le connessioni nel tuo pool di connessioni diventino obsolete e la prima richiesta dell'applicazione da parte di una connessione obsoleta causerà un errore. (A seconda del driver MySQL in uso, l'errore potrebbe spiegare che l'ultimo pacchetto ricevuto con successo ha superato l'impostazione wait_timeout del database). Quindi la tua strategia del pool di connessioni consiste nell'impedire la restituzione di una connessione morta. Le due opzioni seguenti hanno scarsi effetti collaterali per un sito a basso traffico.
-
Aspetta ancora prima di interrompere le connessioni - Lo faresti modificando il valore di
wait_timeoutnella tua configurazione MySQL. In MYSQL workbench puoi trovare facilmente quell'impostazione in Amministratore> File di configurazione> Rete. Per un sito con molto traffico questo non è spesso consigliato perché potrebbe portare il pool a essere sempre riempito con molte connessioni inattive. Ma ricorda che questo è lo scenario a basso traffico. -
Testa ogni connessione - Puoi farlo impostando
testOnBorrow = trueevalidationQuery= "SELECT 1". E le prestazioni? Hai poco traffico in questa situazione. Il test di ogni connessione restituita dal pool non è un problema. Tutto ciò significa che una query aggiuntiva verrà aggiunta a ogni transazione MySQL che stai eseguendo su una singola connessione. Su un sito a basso traffico è davvero qualcosa di cui ti preoccuperai? Il problema delle tue connessioni che si esauriscono nel pool perché non vengono utilizzate è il tuo obiettivo principale.
Traffico medio
- Controlla periodicamente tutte le connessioni -Se non vuoi testare ogni connessione ogni volta che viene utilizzata, o estendere il timeout di attesa, puoi testare periodicamente tutte le connessioni con una query predefinita o personalizzata a tua scelta. Ad esempio, imposta
validationQuery = "SELECT 1",testWhileIdle = "true"etimeBetweenEvictionRunsMillis = "3600"o qualunque intervallo tu voglia. Per un traffico molto basso questo richiederà assolutamente più lavoro. Pensaci. Se hai 30 connessioni nel pool e in 1 ora solo 4 vengono chiamate, allora avresti potuto facilmente controllare tutte e 4 le connessioni su ogni richiesta usando il precedentetestOnBorrowapproccio con scarso successo in termini di prestazioni. Ma se invece esegui l'approccio "Controlla tutto ogni ora", fai 30 richieste per controllare tutte le connessioni quando solo 4 sono state utilizzate.
Traffico elevato
- Uccidi prima le connessioni inattive - Questa è la situazione in cui tutti dicono che non dovresti estendere il wait_timeout e non dovresti testare ogni connessione. Non è un modello ideale per ogni situazione. Quando hai un traffico significativo, tutte le connessioni nel pool verranno utilizzate e il tuo problema reale aumenterà il numero di connessioni disponibili, riducendo di fatto la lunghezza del tuo
wait_timequindi non finisci di caricare molte connessioni inattive sul DB. Ecco un esempio di un tizio che parla di come ha fino a 10.000 connessioni inattive al giorno per un sito occupato, quindi vuole ridurre il wait_timeout Ridurre il wait_timeout per il sito occupato
Configurazione di esempio Context.xml
<Context>
<Resource name="jdbc/TestDB"
auth="Container"
type="javax.sql.DataSource"
factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
testWhileIdle="true"
testOnBorrow="true"
testOnReturn="false"
validationQuery="SELECT 1"
validationInterval="30000"
timeBetweenEvictionRunsMillis="30000"
maxActive="100"
minIdle="10"
maxWait="10000"
initialSize="10"
removeAbandonedTimeout="60"
removeAbandoned="true"
logAbandoned="true"
minEvictableIdleTimeMillis="30000"
jmxEnabled="true"
jdbcInterceptors="org.apache.tomcat.jdbc.pool.interceptor.ConnectionState;
org.apache.tomcat.jdbc.pool.interceptor.StatementFinalizer"
username="root"
password="password"
driverClassName="com.mysql.jdbc.Driver"
url="jdbc:mysql://localhost:3306/mysql"/>
</Context>
Esempio di configurazione web.xml
<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee
http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"
version="2.4">
<description>MySQL Test App</description>
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/TestDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</web-app>
Documentazione sulle proprietà di Tomcat Pool per modificare Tomcat Pool
