Utilizzo di Parallel.For per testare query SQL e il confronto con ThreadPool

Question

Sto cercando un modo per caricare facilmente test e benchmark di alcuni dei nostri SQL (usando ADO.NET, niente di speciale usando LINQ o PLINQ) che devono essere performanti quando funzionano con un carico parallelo elevato.

Ho pensato di utilizzare le nuove estensioni parallele CTP e in particolare Parallel.For / Parallel.ForEach per eseguire semplicemente l'SQL su iterazioni 10k o giù di lì, ma non sono stato in grado di trovare alcun dato su ciò che sono state ottimizzato per.

Essenzialmente sono preoccupato che, poiché l'accesso al database è intrinsecamente associato all'I / O, non creerà un carico sufficiente. Qualcuno sa se parallelo. Perché è abbastanza intelligente da usare & Gt; x thread (dove x = # di CPU) se le attività che sta eseguendo non sono totalmente legate alla CPU? Cioè si comporta in modo simile al pool di thread gestiti?

Sarebbe piuttosto bello se fosse così!

MODIFICA: Come @CVertex ha gentilmente citato di seguito, è possibile impostare il numero di thread in modo indipendente. Qualcuno sa se le librerie parallele per impostazione predefinita sono abbastanza intelligenti da continuare ad aggiungere thread se un lavoro è associato a I / O?

Answer 1

Sicuro!

Puoi specificare il numero massimo di thread per CPU che desideri.

Prima di eseguire Parallel.Per qualsiasi cosa tu faccia, dovrai istanziare il tuo TaskManager dallo spazio dei nomi System.Threading.Tasks. Guarda i parametri ctor per vedere come personalizzare un task manager per i tuoi scopi.

Dovrebbe esserci un sovraccarico per Parallel.Per che richiede un'istanza del task manager.

Answer 2

Un altro modo è definire la variabile d'ambiente PLINQ_DOP. Dai documenti:

PLINQ_DOP
DOP stands for degree of parallelism. Setting this environment variable defines the number of threads for PLINQ to use. 
E.g. PLINQ_DOP=1 means single-threaded, while PLINQ_DOP=8 means PLINQ should use 8 threads. 
If this is set to a value greater than the number of procs*cores available on the system, 
PLINQ will use more threads than processors. If one of them blocks, for instance, 
this allows other threads to make forward progress.