Quasi tutte le istanze cloud posso trovare le impostazioni predefinite di una CPU. Perché questa è solo una CPU adesso, e dovrei aspettarmi un aumento in futuro?
Questo design ha un impatto sulla progettazione del mio codice in modo da escludere tecnologie come Task Parallel Library?
Questo è in argomento per Programmers.SE perché influisce sulla scalabilità a lungo termine del codice muti-threaded sulle piattaforme cloud.
Il cloud computing si occupa di problemi ridicolmente paralleli per impostazione predefinita, come la distribuzione di risorse da un URL. Esistono diversi modi per ottenere il parallelismo, indipendentemente dal numero di core che hai. Dovresti costruire la tua applicazione sapendo come intendi approfittarne. Puoi ottenere istanze cloud con più core e molta RAM, ma costano di più.
La maggior parte dei servizi Web viene eseguita all'interno di un server Web incorporato (ad esempio, i servizi Web Spring Boot). Il parallelismo di cui hai bisogno è curato dal server, quindi finché non aggiungi punti di contesa il tuo servizio rimane ridicolmente parallelo e non devi pensare affatto ai thread.
Detto questo, un servizio può gestire solo così tanti clienti contemporaneamente. Ecco perché le soluzioni cloud generalmente portano un'altra istanza online e distribuiscono il traffico tra le istanze del tuo servizio. Molte volte è molto più economico avere un'altra istanza per un breve burst di traffico piuttosto che avere un'istanza con più core.
Quello che non vedi è che il tuo servizio è solitamente ospitato su un server con più core, ma solo sembra simile a uno per te. Quando hai più copie del tuo servizio web in esecuzione, stai utilizzando anche più core.
Il punto è che il parallelismo è lì, hai solo bisogno di sapere come non rovinarlo. Per questo è necessario capire come funziona il parallelismo, ecc.
Hai menzionato la Libreria parallela attività, e questa è una caratteristica chiave dell'approccio di Microsoft per i servizi web, in particolare se abbinato a async e await . Capire come funziona aiuterà davvero la tua applicazione a gestire più utenti simultanei. È tempo ben speso.
No, in realtà dovresti. Mi spingerei fino al punto di dire - tutti dovrebbero.
La programmazione parallela è in realtà un problema enorme per l'intero settore, è un argomento di cui le università, i tutorial, i project manager e gli architetti di solito evitano. Questo è male, molto male, e dovrebbe essere risolto al più presto.
La programmazione parallela in realtà non è così difficile, ma ha bisogno di una mentalità diversa a cui la maggior parte delle persone non è a suo agio. Le app multi-threaded decenti possono essere scritte solo sapendo e rispettando la regola che tutte le chiamate di funzione dovrebbero essere rientranti e gli oggetti condivisi protetti. Questo risolve la maggior parte dei problemi.
Ma abituarsi a questo è problematico. La documentazione non è sempre thread-aware o non parla esplicitamente di thread. Le reti di sicurezza per il pane e il burro come i test unitari falliscono miseramente nella programmazione parallela. L'unione dei thread e la terminazione / cancellazione anomala sono un problema enorme. E i deadlock sono una cosa spaventosa non appena le persone iniziano a diventare eccessivamente creative.
Questa complessità extra è sufficiente a far sì che la maggior parte delle persone dimentichi i thread in più, diamine, anche io ero abituato a farlo, e anche ora a volte "dimentico" dei thread. Questo è anche un modo perfetto per i fornitori di cloud di dimenticare i multi-core ed eseguire più VM sull'hardware di base.
Ma questo è sbagliato, la crescita della potenza di calcolo è ora nelle discussioni, noi come programmatori dobbiamo abituarci al nuovo mondo e dovremmo provare a usare i thread ogni volta che è possibile.
Di sicuro, dovresti pianificare l'ambiente di esecuzione che prevedi di utilizzare.
La piattaforma cloud che utilizzo mi consente di definire VM con più CPU. Se il parallelismo esplicito è importante per te, seleziona un altro fornitore.
Questo certamente ostacola le prospettive di concorrenza, ma ci sono casi in cui un programma a thread singolo in esecuzione su un singolo core può ancora trarre vantaggio da più thread: ogni volta che il thread attende qualcosa (ad esempio, bloccando IO).
Supponiamo che questo programma esegua un insieme di attività simili in cui ognuna coinvolge il tempo di calcolo C e il tempo di attesa W, quindi per mantenere il single core completamente utilizzato sono necessari i thread W / C.
Ecco la formula generale, date le seguenti definizioni:
Ncpu = numero di CPU
Ucpu = utilizzo della CPU di destinazione; 0 < = Ucpu < = 1
W / C = rapporto tra tempo di attesa e tempo di elaborazione
Il numero ottimale di thread per mantenere le CPU con l'utilizzo dezired è:
Nthreads = Ncpu * Ucpu * (W / C)
Questo significa che più thread non migliorano le prestazioni (solo) quando ci sono più thread eseguibili rispetto alle CPU disponibili.
Generalmente nel cloud si desidera "ridimensionare orizzontalmente" anziché verticalmente. L'aggiunta elastica di VM per gestire i picchi di carico riduce i costi, mentre le CPU / core generalmente non possono essere aggiunti o rimossi elasticamente.
Leggi altre domande sui tag multithreading cpu parallel-programming cloud-computing