Modifica il numero di editori / sottoscrittori in fase di runtime

Avrei il throttling in diretta sul consumatore, dal momento che le tue informazioni finora indicano che tutti i consumatori dovrebbero eseguire allo stesso modo, allo stesso orario. Qualsiasi orchestrazione centralizzata dovrebbe chiedere al nodo qual è il suo utilizzo, effettuare un controllo di soglia di base e poi tornare indietro per dire al consumatore di cambiarsi. Non è necessario il viaggio di andata e ritorno (e il codice commensurato delle comunicazioni) in quanto questa decisione è facilmente realizzabile sul consumatore. Il consumatore può leggere un programma condiviso per sapere quale dovrebbe essere il profilo delle prestazioni in un dato momento. Un'orchestrazione centralizzata potrebbe essere utile se i profili delle prestazioni dovessero cambiare frequentemente e dinamicamente solo per alcuni nodi. Nulla dice che i nodi non possono rileggere periodicamente la configurazione.

È una scelta interessante per eseguire i tuoi utenti su IIS. Non hai problemi di ripristino dell'attività quando il processo di lavoro ricicla inaspettatamente ? Non ho avuto molto successo nell'esecuzione di carichi a lungo termine su IIS. Tuttavia, presumo che sia più conveniente distribuire in questo modo.

MSMQ è lento, ma come dici tu non è il collo di bottiglia. Se fosse possibile, potrei suggerire di mettere un'API di servizio di fronte all'accesso al tuo database in modo da poter controllare un accesso concorrente un po 'di più (magari anche serializzare l'accesso per evitare problemi di blocco). Tuttavia, essendo un'app legacy, presumo che le query vengano eseguite direttamente dai consumatori. Anche allora non sono sicuro che sarebbe sufficiente se hai sproc di lunga data. Ovviamente puoi prendere misure standard come analizzare se gli indici sarebbero utili da aggiungere (o rimuovere).

OK, la mia lettura della tua domanda è che hai dei messaggi su MSMQ che dicono 'fai questa cosa', quando il lavoratore lo prende è praticamente tutto ciò che dice e il lavoratore deve andare al DB per prendere informazioni e aggiornare roba .

Dal mio punto di vista si tratta di un'interpretazione errata del modello di coda, non si sta davvero beneficiando di avere più lavoratori e una coda, perché alla fine della giornata il lavoro è fatto su una singola macchina.

Per renderlo davvero scalabile, devi inserire tutte le informazioni necessarie per eseguire il lavoro nel messaggio e capire come si comporta il lavoro quando altri lavori simili vengono eseguiti contemporaneamente, rendendolo il più possibile atomico.

Dire che il tuo lavoro è prendere alcuni dati di vendita da un DB transazionale e compilare un rapporto, il che significa aggiornare un'altra tabella con alcuni dati aggregati. Il messaggio dovrebbe contenere tutti i "dati di vendita" inseriti e l'output deve essere in grado di aggiornare quella tabella aggregata e contenere il risultato corretto anche se viene eseguito due volte o nell'ordine sbagliato ecc.

In termini pratici, questo potrebbe significare che devi abbattere e ridimensionare il tuo lavoro. Potresti avere:

• Processo A, copia le vendite dei giorni in un file temporaneo
• Processo B, leggi il file temporaneo e invia un altro file di risultati calcolati
• Processo C, leggi i risultati aggregati e calcola se possono essere applicati correttamente alle tabelle del rapporto

I DB sono (quasi) sempre il collo di bottiglia, devi spostare tutta la logica fuori dal DB, senza grossi sproc o pacchetti SSIS. Solo semplici transazioni crude su blocchi di dati di dimensioni note.

Un sistema di Accodamento più complicato ti aiuterà ad orchestrare i tuoi lavori fino a un certo punto, ma in realtà non dovrebbe essere necessario. Le tue macchine worker possono funzionare al 100% 24 ore su 24, 7 giorni su 7, perché è tutto ciò che fanno e, per quanto impegnative, non influiscono sulle prestazioni del resto del sistema