Ho letto la documentazione cercando di capire quando ha senso aumentare la dimensione del pool di thread asincrono tramite l'interruttore + A N.Quando è opportuno aumentare la dimensione del filo asincrono da zero?
Sono perfettamente preparato per il benchmark, ma mi chiedevo se esistesse una regola empirica per quando si dovrebbe sospettare che la crescita della dimensione del pool da 0 a N (o da N a N + M) sarebbe utile .
Grazie
Il BEAM esegue il codice Erlang in thread speciali chiama schedulers. Per impostazione predefinita, avvierà uno scheduler per ogni core del processore. Questo può essere controllato e il tempo di avvio, ad esempio se non si desidera eseguire Erlang su tutti i core, ma "riservare" alcuni per altre cose. Normalmente quando si esegue un'operazione di I/O su file, questa viene eseguita in un programma di pianificazione e, poiché le operazioni di I/O su file sono relativamente lente, bloccano lo scheduler mentre sono in esecuzione. Che può influenzare le proprietà in tempo reale. Normalmente non si esegue molto l'I/O di file, quindi non è un problema.
Il pool di thread asincrono sono thread del sistema operativo utilizzati per operazioni I/O. Normalmente il pool è vuoto ma se si utilizza lo +A all'avvio, BEAM creerà thread in più per questo pool. Questi thread verranno quindi utilizzati solo per le operazioni di I/O dei file, il che significa che i thread del programma di pianificazione non blocceranno più l'attesa per l'I/O del file e le proprietà in tempo reale vengono migliorate. Ovviamente questo costa quanto i thread del sistema operativo non sono gratuiti. I thread non si mescolano in modo che i thread dello scheduler siano solo thread di pianificazione e i thread asincroni siano solo thread asincroni.
Se si scrivono i driver collegati per le porte, è possibile utilizzare anche il pool di thread asincroni. Ma devi scoprire quando sono stati avviati da soli.
Quante ne avete bisogno dipende dalla vostra applicazione. Per impostazione predefinita, nessuno viene avviato. Come @demeshchuk, ho anche sentito che a Riak piace avere un grande pool di thread asincroni mentre aprono molti file. Il mio unico consiglio è provarlo e misurare. Come con tutte le ottimizzazioni?
Per default, il numero di fili in esecuzione Erlang VM è uguale al numero di processori core logici (se si utilizza SMP, ovviamente).
In base alla mia esperienza, l'aumento del parametro + A può migliorare le prestazioni quando si verificano numerose operazioni di I/O su file simultanee. E dubito che l'aumento di + A potrebbe aumentare le prestazioni complessive dei processi, poiché lo scheduler di BEAM è estremamente veloce e ottimizzato.
Parlare dei numeri esatti - che dipende totalmente dalla vostra applicazione, penso. Supponiamo, nel caso di Riak, che il numero massimo di file aperti sia più o meno prevedibile, è possibile impostare + A a questo massimo, o diverse volte meno se è troppo grande (per impostazione predefinita è 64, BTW). Se la tua applicazione contiene milioni di file e li servi ai client web, questa è un'altra storia; molto probabilmente, potresti voler eseguire alcuni benchmark con il tuo codice e il tuo ambiente.
Infine, credo di non aver mai visto + A più di cento. Ciò non significa che non puoi impostarlo, ma probabilmente non ha senso.