MySQL - connessione permanente contro il pool di connessioni

Question

Al fine di evitare il sovraccarico di stabilire una nuova connessione ogni volta che un esigenze di query sparati contro MySQL, ci sono due opzioni disponibili:

1. connessioni persistenti, per cui una nuova connessione è richiesto viene effettuato un controllo per verificare se una connessione "identica" è già aperta e in tal caso utilizzarla.
2. Il pool di connessioni, in cui il client gestisce un pool di connessioni, in modo che ogni thread che deve utilizzare una connessione ne verifichi uno dal pool e lo restituisca al pool al termine.

Quindi, se si prevede che un'applicazione server multithreading debba gestire migliaia di richieste al secondo e ogni thread deve generare una query sul database, qual è l'opzione migliore?

Dal mio punto di vista, Con le connessioni permanenti, tutti i thread nella mia applicazione proveranno ad utilizzare la stessa connessione persistente al database perché utilizzano tutti connessioni identiche. Quindi è una connessione condivisa tra più thread di applicazioni - di conseguenza le richieste si bloccheranno presto sul lato del database.

Se utilizzo un meccanismo di pool di connessioni, farò in modo che tutti i thread dell'applicazione condividano un pool di connessioni. Quindi c'è meno possibilità di una richiesta di blocco. Tuttavia, con il pooling delle connessioni, un thread dell'applicazione dovrebbe attendere di acquisire una connessione dal pool o dovrebbe inviare una richiesta sulle connessioni nel pool in un modo round-robin e lasciare che la coda, se presente, si verifichi nel database?

Answer 1

Avere connessioni persistenti non implica che tutti i thread utilizzino la stessa connessione. Semplicemente "dice" di mantenere aperta la connessione (in contraddizione per aprire una connessione ogni volta che ne hai bisogno). L'apertura di una connessione è un'operazione costosa, quindi, in generale, si tenta di evitare di aprire le connessioni più spesso del necessario.

Questo è il motivo per cui le applicazioni multithread utilizzano spesso pool di connessioni. Il pool si occupa delle connessioni di apertura e chiusura e ogni thread che richiede una connessione ne richiede uno dal pool. È importante fare in modo che il thread restituisca la connessione il prima possibile al pool, in modo che un altro thread possa utilizzarlo.

Se l'applicazione ha solo alcuni thread a lunga esecuzione che richiedono connessioni, è inoltre possibile aprire una connessione per ciascun thread e mantenerlo aperto.

L'utilizzo di una sola connessione (come è stata descritta) equivale a un pool di connessione con la dimensione massima. Questo sarà prima o poi il collo di bottiglia dato che tutti i thread dovranno attendere la connessione. Questa potrebbe essere un'opzione per serializzare le operazioni del database (eseguirle in un certo ordine), sebbene ci siano opzioni migliori per garantire la serializzazione.

Answer 2

Per quanto riguarda la domanda in merito al server delle applicazioni in attesa di una connessione, la risposta è sì.

Le connessioni MySQL stanno bloccando. Quando si invia una richiesta dal server MySQL su una connessione, la connessione attenderà, inattiva, finché non si riceve una risposta dal server.

Non c'è modo di inviare due richieste sulla stessa connessione e vedere quali restituisce per prime. È possibile inviare una sola richiesta alla volta.

Quindi, in genere, un singolo thread in un pool di connessione è costituito da una connessione lato client (nel caso specifico, il server delle applicazioni è il client) e una connessione lato server (database).

L'applicazione deve attendere un thread di connessione disponibile dal pool, consentendo al pool di crescere quando è necessario e di ridursi al numero predefinito di thread, quando è meno occupato.