In che modo il pooling di connessioni al database migliora le prestazioni delle applicazioni?

3

Non riesco a capire perché il pooling delle connessioni migliora le prestazioni delle applicazioni.

Suppongo che la connessione stabilisca la latenza. Ma riutilizzare una connessione stabilita richiede una gestione degli errori più complessa. Il server delle applicazioni deve tenere traccia dello stato di ogni connessione per impostare la connessione allo stato iniziale prima di riutilizzare (come ad esempio eliminare tutte le transazioni, passare al livello di isolamento predefinito), il che costa anche tempo.

    
posta Sherwood Wang 31.01.2014 - 05:38
fonte

3 risposte

5

La complessa gestione degli errori è solitamente fornita dalle librerie e, se la tua applicazione è ben educata, non dovrebbe comunque essere necessaria troppo. È molto più probabile che venga invocata la complessa gestione degli errori richiesta durante il tentativo di creare una nuova connessione.

Il ripristino dello stato della connessione è banale e poco costoso; è integrato in tutti i moderni gestori di connessioni di cui sono a conoscenza.

Nulla può ridurre i costi generali della creazione di una nuova connessione a un database.

    
risposta data 31.01.2014 - 07:02
fonte
2

L'apertura di una nuova connessione richiede un tempo lungo : le librerie client devono stabilire a quale server comunicare, quindi aprire una negoziazione con quel server per ottenere una connessione iniziale, quindi riavviare le credenziali e avanti per autenticare il client, quindi avviare una sessione di database e [finalmente] configurare quella sessione nel modo desiderato dall'applicazione.
Lento!

Le connessioni in pool consentono di eliminare la maggior parte (ma non tutte) di quel sovraccarico con nessun lavoro aggiuntivo sulla parte dell'applicazione. La maggior parte della gestione degli errori non è in grado di accedere al database in primo luogo.

Ottimo per le applicazioni web, in cui il server web deve entrare, fare qualcosa e uscire di nuovo, più e più volte per una moltitudine di client diversi.

Non così buono per, diciamo, un servizio di Windows che è in esecuzione "in background" 24x7 ma dove il database sottostante "scompare" per "un po 'di tempo" ogni notte per le attività di manutenzione e altre attività di manutenzione.
Certo, si potrebbe chiudere il servizio mentre sta succedendo, ma (in assenza di qualsiasi modo gestito di farlo al momento) la nostra soluzione era quella di costruire l'applicazione per trattare il suo database come un'entità transitoria. Stabiliva una connessione al database quando poteva e quindi lo teneva aperto e, ogni volta che voleva usare il database, quasi si aspettava che fosse "scomparso". E sì, la gestione degli errori aveva bisogno di era molto più complicato, ma quel servizio è stato eseguito abbastanza felicemente per un decennio e mezzo! (OK, not continuamente, l'host viene riavviato ogni mese per il patching).

    
risposta data 31.01.2014 - 14:08
fonte
1

Soprattutto perché il server delle applicazioni ha un pool di connessioni database aperte e pronte per l'uso.

Se il programma dovesse connettersi e accedere al database ogni volta che lo rallenterebbe considerevolmente.

Esistono altri vantaggi, come la gestione di tutte le variazioni nella connessione a diversi DBMS di fornitori diversi e la gestione della configurazione della connessione in modo coerente e gestibile. Immagina se avessi 100 servizi che hanno reso la tua connessione a un dq MySql e il tuo manager ti ha detto di connetterti a Postgress. Con un server delle applicazioni J2EE ciò comporterebbe la modifica di alcune voci in un singolo file di configurazione, senza il pooling delle connessioni sarebbe necessario apportare modifiche in 100 programmi applicativi.

    
risposta data 31.01.2014 - 07:17
fonte

Leggi altre domande sui tag