Le web app rappresentano lo strumento principale che possiamo adottare sulla piattaforma cloud di Microsoft per ospitare i nostri siti, front end o back end. Data la flessibilità di cui dispongono, è normale disporre di più istanze il cui carico viene automaticamente bilanciato tramite round robin. Le istanze poi, possono variare durante la giornata a seconda delle regole di auto scaling, in base ad orari fissi o a seconda dei carichi di CPU o di memoria.
In tutte le situazioni in cui la nostra web app effettua delle elaborazioni, tramite framework come ASP.NET, Java, PHP o node.js, la prima esecuzione della nostra web app è più lenta e può richiedere anche diversi secondi. Con la flessibilità di istanza illustrata in precedenza, inoltre, può verificarsi che un utente si trovi ad essere il primo ad effettuare la richiesta ad un nuovo server, trovandosi con lunghi tempi di risposta.
Per ovviare a questo problema IIS 8 dispone di un modulo nativo, utilizzabile con qualsiasi framework web, che si occupa di effettuare il warmup del nostro applicativo. L'aspetto interessante è che IIS è in grado comunque di restituire contenuti statici e quindi possiamo sfruttare una pagina HTML di attesa. Per usufruire di questa funzionalità dobbiamo intervenire sulla sezione system.webServer.
<configuration> <system.webServer> <applicationInitialization doAppInitAfterRestart="true" remapManagedRequestsTo="startup.html" skipManagedModules="true"> <add initializationPage="/default.aspx" /> <!-- hostName facoltativo --> <add initializationPage="/home/index" hostName="miodominio.it" /> </applicationInitialization> </configuration> </system.webServer>
Innanzitutto notiamo che nell'elemento applicationInitialization possiamo indicare uno o più URI da richiamare, dei quali però ignora l'esito. Il compito di IIS è di chiamare gli indirizzi nell'ordine stabilito, aspettandone l'esito, e si occupa di farlo anche in caso di riavvio, grazie all'attributo doAppInitAfterRestart. Con l'attributo remapManagedRequestsTo, invece, indichiamo facoltativamente la pagina da restituire all'utente, qualunque sia l'indirizzo che chiede; se omesso IIS restituisce un 503. Nel nostro caso, la pagina startup.html può essere come la seguente, la quale cerca di ricaricare la pagina fino a quando verrà restituito il contenuto reale dell'applicativo.
<html> <head> <!-- refresh dopo 5 secondi --> <meta http-equiv="refresh" content="5"> </head> <body> Avvio in corso </body> </html>
L'aspetto più interessante è relativo al load balancer di Azure. Se nessuna istanza è pronta, restituisce la pagina HTML, mentre se almeno un'istanza è pronta, manda l'utente tra quelle disponibili, fino a quando nuove istanze si possono sfruttare. Il risultato è un'ottima esperienza utente che non nota il variare dei server che mettiamo a disposizione.
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Migliorare l'organizzazione delle risorse con Azure Policy
Configurare il nome della run di un workflow di GitHub in base al contesto di esecuzione
Conoscere il rendering Server o WebAssembly a runtime in Blazor
Recuperare l'ultima versione di una release di GitHub
Usare i settings di serializzazione/deserializzazione di System.Text.Json di ASP.NET all'interno di un'applicazione non web
Utilizzare EF.Constant per evitare la parametrizzazione di query SQL
Managed deployment strategy in Azure DevOps
Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
Persistere la ChatHistory di Semantic Kernel in ASP.NET Core Web API per GPT
Utilizzare QuickGrid di Blazor con Entity Framework
Generare velocemente pagine CRUD in Blazor con QuickGrid
Simulare Azure Cosmos DB in locale con Docker