Esegui la procedura in parallelo o asincrono

0

Ho ereditato un'applicazione che esegue circa 100.000 esecuzioni in un ciclo for C # contro SQL Server.

for (int i=0; i<100000; i++)
{
  //Execution can take 0.250 to 5 seconds to complete.
  ExecuteProc(i); // no result returned
}

Per ridurre il tempo necessario per eseguire tutte le 100.000 procedure, sarebbe meglio:

  1. converti questo ciclo in un foreach parallelo .Net loop o
  2. eseguire la procedura in modo asincrono?
posta TheLegendaryCopyCoder 27.08.2016 - 13:29
fonte

3 risposte

3

Sembra che tu stia cercando di aggiustare la cosa sbagliata qui. Perché hai anche 100.000 sproc (o esegui lo stesso set di sproc 100.000 volte). Scommetto che questo problema potrebbe essere risolto semplicemente scrivendo qualche SQL migliore che non richiede questo tipo di follia.

Inoltre ... Gli approcci paralleli / asincroni sono una cattiva idea se l'ordine di esecuzione è importante. Se l'ordine è importante ... Non puoi farlo.

    
risposta data 27.08.2016 - 15:32
fonte
2

Dovresti provare a inserire il ciclo nel database.

Guidare il database esternamente per eseguire le 100.000 operazioni in parallelo probabilmente danneggerà il database e probabilmente non avrà la consapevolezza di risolverlo in alcun modo ragionevole, perché non avrà la possibilità di vedere il problema più grande.

Se riesci a spingere il loop nel database, esso (1) ridurrà al minimo il sovraccarico di andata e ritorno e, (2) darà al database una possibilità di combattere nel vedere l'intera dimensione del problema che stai chiedendo di risolvi, quindi potresti solo immaginare un modo per parallelizzare o usare più thread su quel problema più grande.

(Non sappiamo cosa fa ExecuteProc ma se lo facessimo, è ipotizzabile che poteste eliminare le 100.000 esecuzioni con un proc memorizzato diverso, forse più grande e più complesso.)

    
risposta data 28.08.2016 - 02:55
fonte
1

ExecuteProc è una chiamata asincrona? se stai facendo IO (e le richieste web sono IO), la generazione di un thread di bajillion che ogni attesa di un'operazione sincrona rischia semplicemente di legare tutti i thread in modo che non possano svolgere un lavoro utile. staranno tutti dormendo fino al termine della chiamata.

Se hai accesso a una API asincrona, la quantità di thread non è super importante, perché non c'è praticamente alcun lavoro della CPU coinvolto nell'invio di una query a un server SQL.

Se hai solo un'API sincrona, la paralellizzazione può velocizzare le cose, ma sarà molto più dispendiosa in termini di risorse. prova le tue opzioni e misura quello che ti conviene. solo tu sai quali sono i tuoi limiti.

    
risposta data 27.08.2016 - 14:15
fonte