Stream di Akka - immissione di un flusso legato all'IO su un dispatcher diverso

Question

Il mio stream ha un mix uniforme di CPU bound e livelli di IO bound (ogni fase IO è seguita da uno stage CPU). Quello che voglio fare è mettere le operazioni IO su un dispatcher diverso rispetto al resto del flusso.

In un'applicazione Akka basata su attore tradizionale, avrei potuto mettere i miei attori IO su un dispatcher di pool di thread fissi con molti thread mentre mettevo gli attori legati alla CPU su un pool di fork join con un piccolo numero di thread (alcuni multipli, idealmente 1, del numero di core). Questo dovrebbe ridurre il tempo sprecato nel cambio di thread per gli attori legati alla CPU mentre aumenta il throughput avendo un sacco di thread che bloccano su IO.

Questa intesa è corretta? Se no, perché? Se sì, allora come faccio a inserire i miei stadi rilegati IO (flussi) su un dispatcher separato dal resto del flusso?

Ho provato a disattivare l'auto-fusione e questo aiuta. Ma ha ancora un throughput molto minore rispetto alla controparte Akka quasi equivalente.

Answer 1

il default è che tutte le fasi di un flusso viene eseguito sullo stesso attore, è possibile contrassegnare che stadi devono funzionare su un dispatcher separata utilizzando attributi, in questo modo:

stage.withAttributes(ActorAttributes.dispatcher("dispatcher-name")) 

Questo introdurrà anche i confini asincroni attorno a quel palcoscenico, gestendolo efficacemente nel proprio attore. Per evitare che il confine asincrono diventi costoso, lo stage ora invierà effettivamente la richiesta di 16 elementi alla volta da upstream, quindi questo è qualcosa che devi essere a conoscenza.

La dimensione del buffer può essere ottimizzata con un attributo aggiuntivo, in questo caso facendolo comportarsi come fasi fuse in quanto richiede un elemento alla volta, si noti che questo può dare troppo sovraccarico, a seconda del caso d'uso.

stage.withAttributes(Attributes.inputBuffer(1, 1)) 

parti rilevanti dei documenti:

• buffers for asynchronous stages
• attributes
• pipelining and parallelism