3 messaggi dal 09 dicembre 2011
Dovro' realizzare in ambiente intranet un cruscotto di monitoraggio fomato da una pagina web form dove sono mostrati dai 10 ai 15 indicatori.

Ogni indicatore e' pilotato da query abbastanza pesanti.

Ogni sezione della pagina dovrebbe aggiornarsi dinamicamente e separatamente in base all'arrivo delle risposte e non rimanere in attesa che tutte le query siano terminate.
In questo modo l'utente, anche se dovra' aspettare, vedra' via via la pagina comporsi.

La mia idea sarebbe quella di sfruttare il parallelismo delle query.

Sono un po' indeciso sulla corretta tecnologia da usare:

Task Parallel

Asinc Await

Thread

Inoltre, invece di utilizzare query/stored dirette sul DB, sarebbe consigliabile realizzare e chiamare vari Web Services ?

Qual'e' l'approccio migliore soprattutto per non bloccare la UI ?

Grazie per il vostro contributo.

Antonio
11.868 messaggi dal 09 febbraio 2002
Contributi
Ciao Antonio,
certamente, se stai usando il .NET Framework 4.5 puoi avvalerti del pattern async/await quando rivolgi le tue query al database. In questo modo IIS potrà riutilizzare gli stessi thread per rispondere ad altre richieste, nell'attesa che il database restituisca un risultato.

Secondo me, però, non dovresti lanciare parallelamente varie queries lato server perché così l'utente è costretto ad aspettare il tempo della query più lunga, prima che venga visualizzato qualsiasi cosa a video.

Invece, potresti realizzare un cruscotto perssoché vuoto, che perciò si caricherà quasi istantaneamente. L'utente vedrà apparire una pagina contenente solo il menu e il footer. Il corpo centrale, inizialmente, sarà completamente bianco.
A questo punto, a pagina caricata, dovresti lanciare una o più richieste ajax al server. Ciascuna richiesta ajax, lato server, verrà gestita dall'action di un controller (se MVC) o da un Page Method (se WebForms) o da un webservice che si occuperà di ottenere e restituire i per quel solo indicatore (qui assumo che 1 richiesta ajax = 1 query = 1 indicatore).

Mentre le richieste ajax fanno il loro corso, l'utente a video vedrà 15 iconcine "loading" che, man mano che le richieste ajax vengono completate, verranno sostituite dall'indicatore. Questo gli darà l'impressione di un'applicazione reattiva, che fa del suo meglio nei confronti di queries che richiedono molto tempo.

Decidi tu il grado di parallelismo delle richieste ajax: non sempre è conveniente "spararle" tutte insieme. Potresti lanciarne 2-3 contemporaneamente come vedi in questo esempio. Vedi cosa ti dà prestazioni migliori.

Se l'intranet ha tanti utenti che vogliono visualizzare il cruscotto contemporaneamente, potresti adottare del caching per rispondere velocemente alle loro richieste. Devi domandarti se dati vecchi di 5-10 minuti (o anche di un'ora) sono comunque da considerarsi accetabili.
In questo modo hai prestazioni nettamente superiori con molti utenti al costo di visualizzare dati non proprio aggiornatissimi.


sarebbe consigliabile realizzare e chiamare vari Web Services ?

No, perché tanto il collo di bottiglia è rappresentato dal disco su cui sono memorizzati i dati. Il modo con cui è stata costruita l'applicazione è indifferente nei riguardi delle prestazioni. Ti conviene scegliere il design che reputi più semplice (una Web API o un WebService vanno bene, così come altre soluzioni. Spiega cosa hai realizzato finora).

ciao,
Moreno
Modificato da BrightSoul il 20 settembre 2015 12.38 -

Enjoy learning and just keep making
3 messaggi dal 09 dicembre 2011
Moreno
la situazione che hai immaginato e' corretta.
Mi stavo focalizzando troppo sul parallelismo, in effetti essendo il DB Server unico, non otterei grandi vantaggi.
OK anche per il caching gia' uso questa "tattica" in scenari simili.
Grazie terro' conto delle tue preziose informazioni.

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.