Alcuni direbbero che due thread sono troppi: non sono proprio in quel campo :-)
Ecco il mio consiglio: misura, non indovinare. Un suggerimento è di renderlo configurabile e inizialmente impostarlo su 100, quindi rilasciare il software allo stato brado e monitorare ciò che accade.
Se l'utilizzo del thread raggiunge il picco a 3, 100 è troppo. Se rimane a 100 per la maggior parte della giornata, aumentalo fino a 200 e vedi cosa succede.
Si potrebbe in realtà avere il codice stesso monitorare l'utilizzo e regolare la configurazione per la prossima volta che si avvia ma questo è probabilmente eccessivo.
Per chiarimenti ed elaborazione:
Non sto proponendo di far rotolare il tuo sottosistema di pool di thread, usa sicuramente quello che hai. Ma, dal momento che stavi chiedendo un buon punto di interruzione per i thread, suppongo che l'implementazione del pool di thread abbia la capacità di limitare il numero massimo di thread creati (che è una buona cosa).
Ho scritto il codice di pooling delle connessioni di thread e database e hanno le seguenti funzionalità (che credo siano essenziali per le prestazioni):
- un numero minimo di thread attivi.
- un numero massimo di thread.
- chiusura di thread non utilizzati da un po 'di tempo.
Il primo imposta una linea di base per le prestazioni minime in termini di client del pool di thread (questo numero di thread è sempre disponibile per l'uso). Il secondo imposta una restrizione sull'utilizzo delle risorse da parte dei thread attivi. Il terzo ti riporta alla baseline in periodi di silenzio in modo da ridurre al minimo l'uso delle risorse.
È necessario bilanciare l'utilizzo delle risorse di thread non utilizzati (A) rispetto all'utilizzo delle risorse di non disporre di thread sufficienti per eseguire il lavoro (B).
(A) è generalmente l'utilizzo della memoria (stack e così via) poiché un thread che non fa alcun lavoro non utilizzerà gran parte della CPU. (B) sarà generalmente un ritardo nell'elaborazione delle richieste quando arrivano poiché è necessario attendere che una discussione diventi disponibile.
Ecco perché misuri. Come dici, la stragrande maggioranza dei tuoi thread aspetterà una risposta dal database in modo che non siano in esecuzione. Ci sono due fattori che influenzano il numero di thread che dovresti consentire.
Il primo è il numero di connessioni DB disponibili. Questo potrebbe essere un limite rigido a meno che tu non possa aumentarlo nel DBMS - suppongo che il tuo DBMS possa prendere un numero illimitato di connessioni in questo caso (anche se idealmente dovresti anche misurarlo).
Quindi, il numero di thread che dovresti avere dipende dal tuo uso storico. Il minimo che dovresti avere è il numero minimo che tu abbia mai avuto in esecuzione + A%, con un minimo assoluto di (ad esempio, e rendilo configurabile proprio come A) 5.
Il numero massimo di thread dovrebbe essere il massimo storico + B%.
Dovresti anche monitorare i cambiamenti di comportamento. Se, per qualche motivo, l'utilizzo va al 100% di quello disponibile per un periodo di tempo significativo (in modo da influire sulle prestazioni dei clienti), è necessario aumentare il massimo consentito fino a quando non sarà nuovamente superiore del B%.
In risposta a "cosa devo misurare esattamente?" domanda:
Quello che dovresti misurare specificamente è la quantità massima di thread in uso simultaneo (ad esempio, in attesa di un ritorno dalla chiamata DB) sotto carico. Quindi aggiungi un fattore di sicurezza del 10% per esempio (sottolineato, poiché altri poster sembrano prendere i miei esempi come raccomandazioni fisse).
Inoltre, ciò dovrebbe essere fatto nell'ambiente di produzione per l'ottimizzazione. Va bene ottenere un preventivo in anticipo, ma non si sa mai quale produzione si farà strada (motivo per cui tutte queste cose dovrebbero essere configurabili in fase di esecuzione). Questo per cogliere una situazione come il raddoppio imprevisto delle chiamate client in arrivo.