Le seguenti osservazioni sono valide per WF 3.0, non ho ancora fatto prove sul 3.5.
Una notizia interessante riportata da MSDN a proposito della proprietà MaxSimultaneousWorkflows della classe DefaultWorkflowSchedulerService è la sequente:
"The default value for this method is 5 for a single-processor machine, and (int)(5 * Environment.ProcessorCount * .8) for a multiple-processor machine...".
Questo significa che, se non diversamente specificato, il WF Runtime è in grado di eseguire 5 workflow concorrenti su una macchina mono-processore, che diventano 8 con un processore Hyper-Threading.
Cosa fare se si vuole scavalcare questo limite e non si può/vuole aumentare il numero di processori?
La proprietà MaxSimultaneousWorkflows è read-only, quindi si deve agire al momento della configurazione dei servizi, in uno dei due seguenti modi:
- creare esplicitamente l'istanza di DefaultWorkflowSchedulerService utilizzando il costruttore che riceve il numero massimo di workfllow simultanei, ed iniettare successivamente il servizio nel WF Runtime. Qui c'è un esempio di come fare;
- configurare il servizio attraverso l'app.config del processo che ospita il runtime. Qui c'è l'esempio.
Attenzione però: il servizio DefaultWorkflowSchedulerService richiede i thread al thread pool di .NET. Quest'ultimo, se pesantemente sollecitato, può andare incontro a fenomeni di starvation capaci di compromettere il funzionamento dell'applicazione.
In casi del genere, fornendo un proprio servizio derivato da WorkflowSchedulerService, si può tentare di applicare una strategia di threading fatta su misura per il problema specifico.