Come si decide il numero di connessioni richieste nel pool di connessioni?

Question

Sto utilizzando Hibernate 3.2.2 nella mia applicazione. Per il pooling di connessioni, stiamo usando c3p0 0.9.1. Sto usando Pattern DAO generico e Open Session in Visualizza modello per eseguire operazioni sul database.
Stiamo lavorando al nuovo sito Web del sito web esistente. In questo momento, il numero di visite è di mezzo milione di visite di pagina nell'applicazione esistente. Sono confuso con la configurazione di c3p0. A quale benchmark, decido di aprire il no di connessione. max-connection, min-connection, idletime, timeout, ecc ....

Answer 1

Prima è necessario determinare cosa farà il pool in caso di richiesta e non ci sarà alcuna connessione gratuita per servirlo. Fa un'eccezione? Restituire null? Blocca fino a quando non viene restituita un'altra connessione al pool?

Una volta che sai cosa succederà quando la capacità viene superata, pensa a come potresti gestirlo nel codice chiamante e in quali situazioni è accettabile che ciò accada. Ad un certo punto man mano che aumenta il numero di connessioni, dovrai iniziare a rifiutare di servire alcune richieste, ma solo tu puoi decidere quale sia quel punto. Il punto reale dipende da molti fattori, tra cui cose come

• tuo Corrente al minimo e la velocità di richiesta occupato
• la volatilità di questi tassi (si vuole di più "di respiro" se i tassi di saltare in giro un sacco
• eventuali proiezioni future per l'aumento di capacità rispetto ai miglioramenti hardware e il tempo di sviluppo preventivato per rivedere questo codice (se si prevede di aggiornarlo in un paio di mesi, è necessario meno sovraccarico rispetto a se è destinato a continuare a correre per un paio di anni)
• qualsiasi garanzia della capacità di elaborazione dell'azienda
• la capacità dei clienti di comprendere le richieste "riprova più tardi" - ad es. se sai che è uno script automatico dall'altra parte che dorme per un minuto su un 503 e ci riprova, è meglio di un umano ricevere un messaggio di "capacità temporaneamente superata" ed entrambi sono molto meglio di uno script batch che ottiene un 200 risposte e si chiude semplicemente con un errore.
• l'urgenza delle richieste - alcune richieste (guardando le foto dei gattini) possono essere ragionevolmente ritardate, ma altre (ordini di compravendita) possono essere molto sensibili al fattore tempo.

E così via e così via.

Speriamo che da quanto sopra si dovrebbe essere in grado di venire con il numero di richieste è necessario essere in grado di elaborare contemporaneamente (e se ci sono diversi tipi di richiesta, può essere necessario tenerne preoccupazione troppo) . Quindi si tratta solo di osservare come le richieste in entrata vengono acquisite e utilizzare le connessioni, il ragionamento e il profilo fino a quando non si scopre il numero di connessioni nel pool necessario per mantenere la velocità di connessione desiderata.

Non dimenticare di tenere conto di argomenti come i thread non richiesti (ad es. Pool di lavoratori) che ottengono le proprie connessioni dallo stesso pool (il pool deve essere più grande), nonché le richieste che mantengono solo una connessione per parte del loro esecuzione (la piscina può essere più piccola).

Answer 2

Definire le istanze di test, apportare piccole modifiche di configurazione e infine verificare con il test di carico.