2013-01-21 3 views
5

Sto scrivendo un'applicazione sul framework di gioco 2.0. Lo scopo di questa app è gestire i caricamenti di immagini e ridimensionarli in background.Nei playframework come faccio a dare priorità ai thread io sugli attori di akka?

Il caricamento viene gestito tramite un gestore di posta standard che salva il file nel filesystem. In questo momento questo è appena fatto sull'evento o sul thread IO. Una volta che il file è stato salvato con successo, a un attore AKKA viene inviato un messaggio per ridimensionare l'immagine originale a un numero di dimensioni diverse (attualmente 4). Queste operazioni di ridimensionamento richiedono CPU e richiedono un po 'di tempo.

Questo funziona tutto bene, fino a quando non testare l'app con un certo carico. Sotto carico, le operazioni di ridimensionamento stanno consumando in modo efficace tutto il tempo di CPU disponibile e quindi le richieste HTTP in arrivo sono in qualche modo affamate per il tempo della CPU e vediamo un backlog di queste richieste al punto che alla fine le richieste iniziano a scadere.

Quindi la domanda è: come configurare il sistema (o riscriverlo) per dare alle richieste HTTP in arrivo una priorità maggiore rispetto alle richieste di ridimensionamento?

+1

Argomento interessante, hai considerato l'utilizzo di librerie grafiche esterne + la creazione della coda di immagini da ridimensionare (ad es. In DB)? in tal caso si potrebbe semplicemente rallentare l'esecuzione della coda o addirittura interromperla in caso di traffico enorme – biesior

+0

Stiamo cercando di migrare dalle immagini di accodamento nel db a causa di problemi di spazio. – harmanjd

risposta

3

Si consiglia di verificare dispatcher in Akka. Fondamentalmente sono thread/worker pool astratti che ogni attore usa per l'elaborazione. È possibile definire un dispatcher globale o diversi.

Definire dispatcher avendo solo un numero limitato di fili (1 o 2):

resizing-thread-pool-dispatcher { 
    type = Dispatcher 
    executor = "thread-pool-executor" 
    thread-pool-executor { 
    core-pool-size-max = 1 
    } 
} 

e associarlo con il ridimensionamento attore:

context. 
    actorOf(
    Props[ResizingActor].withDispatcher("resizing-thread-pool-dispatcher"), 
    "resizingActor" 
) 

Naturalmente l'idea è che il vostro resizing-thread-pool-dispatcher consuma meno thread i core disponibili, quindi i thread HTTP sono ancora reattivi.