Elaborazione delle attività in coda in parallelo?

Penso che tu abbia l'idea giusta: avere un thread / processo / applicazione di monitoraggio che non fa altro che monitorare . Se vede attività che necessitano di elaborazione, le maneggia al più presto possibile in modo che possa tornare al suo lavoro - monitoraggio.

Molto tempo fa un sacco di daemon Unix (server ftp, ecc.) erano scritti in quel modo. Un thread ascolterebbe sulla porta per i messaggi in arrivo. Non appena è arrivato un messaggio, quel thread genererà un nuovo thread per elaborare il messaggio e il thread originale tornerà ad ascoltare.

Poiché questo è ora il 21 ^st secolo, puoi farlo nel modo più semplice? Convertire ogni richiesta di attività in una chiamata Web, quindi eseguirla attraverso un sistema di bilanciamento del carico a un gruppo di macchine worker? Sembra controintuitivo (dal momento che l'elaborazione di una singola attività potrebbe richiedere un po 'più di tempo), ma sarà abbastanza facile mantenere la parallelizzazione.

I thread di spawning sul box locale sono certamente anche un'opzione. Se stai usando Windows ci sono alcuni strumenti che rendono relativamente facile la gestione del pool di thread per te in modo da non dover tenere traccia del numero di thread che hai generato. Se possibile, prova a creare thread "fire & forget" (cioè non bloccanti).

Questo ha meno a che fare con il parallelismo, quindi ha a che fare con il polling del database rispetto alla messaggistica.

È possibile rendere parallela la soluzione corrente semplicemente aggiungendo un passaggio in cui il processo esamina il numero di attività e decide se desidera assistenza. Se lo fa inizia un'altra attività. Oh, vorrai contrassegnare un'attività come in sospeso quando qualcosa ha iniziato a funzionare ma non ha finito.

Bang, zowie, sei parallelo. Grande woop.

Tutto ciò che ho appena detto deve essere fatto in modo transazionale. Ciò significa che ha overhead. Certo è parallelo ma ciò non significa che non ci sia un modo più veloce.

Un sistema di messaggistica consentirebbe ai clienti di avviare i processi che gestiscono le loro richieste direttamente e immediatamente. Quando le risorse sono sopraffatte, ciò farebbe ancora la fila. Il problema è che devi riscrivere i client che erano soliti parlare al database per parlare ora usando il sistema di messaggistica.

Se riscrivere i client per parlare con un sistema di messaggistica è un no, puoi imbrogliare. Metti uno sniffer di pacchetti sul database e analizza le richieste. Appena li incontri, puoi iniziare a lavorarci su. Sbrigati perché apparentemente 60 secondi è troppo tempo per aspettare.

La generazione di nuovi thread ha un notevole overhead del sistema operativo o imposta l'ambiente, vorrei anche che ogni task cercasse più lavoro sulla coda e terminasse quando non si trovava nessuno.