47 messaggi dal 12 agosto 2009
Si verifica un problema nell'esecuzione dei servizi.

Viene monitorate il tempo di esecuzione di una action i.e:

 [AllowAnonymous]
 public IActionResult Index()
 {
       try
       {
           this.Tracer.Message($"Start of home index ...");
           .....
       }
       catch (System.Exception ex)
       {
            ....
       }
       finally(System.Exception ex)
       {
           this.Tracer.Message($"End of home index ...");
       }

       return View();
}



E tale controller viene eseguito in tempi ragionevoli
Ma il server a rispondere impiega molto più tempo....

Ho aggiunto nella pipeline la seguente azione:



app.Use(async (context, next) =>
{
               
              
   var Tracer = new NexusAT.QArc.Base.Tracer("Rem.WWW", "Rem.WWW.UI", "Root");
   var sw = new System.Diagnostics.Stopwatch();
   sw.Start();
   await next.Invoke();
   sw.Stop();
   Tracer.Message(String.Format("... execution time: {0}: {1} ms", context.Request.Path.Value, sw.ElapsedMilliseconds));
                
});



Tra il return della action e il return dell'azione passano anche 8 secondi.
Quale può essere la causa?
Modificato da eomer1975 il 29 maggio 2017 10.53 -
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,
per il momento, in mancanza di altri elementi, penso che l'attesa dipenda dal codice utente, cioè dalle istruzioni che hai messo nell'action.

Prova a misurare il tempo di attesa di un'action banale come questa:
public async Task<IActionResult> Prova()
{
  return Content("Ciao");
}


Ottieni comunque un tempo di attesa di 8 secondi?

Comunque, quello che hai fatto per misurare il tempo penso sia corretto. Metti il tuo app.Use subito prima di app.UseMvc, così misuri l'effettivo tempo impiegato dal middleware di routing di MVC ad elaborare la richiesta.

Se scopri che il tempo è molto breve, sposta il tuo app.Use più in alto, cioè prima di altri middleware. Continua a spostarlo in alto finché non trovi quello che sta causando la lentezza.

Fammi sapere cosa scopri, poi possiamo continuare la discussione con questi nuovi elementi.

ciao,
Moreno

Enjoy learning and just keep making
47 messaggi dal 12 agosto 2009
In realtà la risposta va bene.
Ma ogni tanto si termina il processo kestrel. Quando il worker process lo riavvia passano 8 secondi.

Prima poteva capitare che il processo venisse terminato e ricaricato tra chiamate diverse della stessa sessione finchè non è stato impostato nell application pool per l'applicazione in question StartMode = AlwaysRunning.

Ora per la sessione non si ha più il riavvio del processo kernel.
Ma si termina lo stesso, forse quando in non attività.
11.886 messaggi dal 09 febbraio 2002
Contributi
Ciao,
aver impostato AlwaysRunning dovrebbe già essere sufficiente a garantirti che l'applicazione sia sempre immediatamente disponibile a rispondere alle richieste.

Per sicurezza imposta anche il Timeout di Inattività a 0, dalle impostazioni avanzate dell'application pool.

Inoltre, verifica nel Visualizzatore eventi di Windows appaiono degli errori che possano aver mandato in crash l'applicazione.

Kestrel non lo conosco ancora abbastanza bene da sapere se ha esso stesso dei meccanismi interni (configurabili) che si attivano dopo un certo tempo di inattività.

Prova a leggere questa issue, vedi se qualcuno di quei consigli può aiutarti.
https://github.com/aspnet/Hosting/issues/522

Inoltre ti consiglierei di verificare come si comporta l'applicazione quando rivolgi le tue richieste direttamente a Kestrel (cioè senza passare per IIS). ATTENZIONE! Fallo solo mentre la tua webapp è al sicuro all'interno della tua rete locale. Non è quello di esporre Kestrel su internet.

Se riesci a fare questa prova almeno capiamo in quale dei due webserver si trova il problema.

ciao,
Moreno

Enjoy learning and just keep making
47 messaggi dal 12 agosto 2009
Ho impostato idle Time-out (minutes) a 0.
Sembra andare meglio.

Prima ho provato a debuggare il processo .net core, ma è terminato senza errori.

Grazie
47 messaggi dal 12 agosto 2009
Ho scoperto il motivo: impiega 7 second a compilare index.cshtm!
Quindi la cosa si ripropone ogni qual volta si riavvia il processo Kestrel.



Dal log di kestrel:
dbug: Microsoft.AspNetCore.Mvc.Razor.Internal.DefaultRoslynCompilationService[2]
      => RequestId:0HL5JO68SCMUN RequestPath:/Rem => NomeCliente.NomeApp.WWW.Web.Controllers.HomeController.Index (NomeCliente.NomeApp.WWW.Web)
      Compilation of the generated code for the Razor file at '/Views/Home/Index.cshtml' completed in 7447.2905ms.
11.886 messaggi dal 09 febbraio 2002
Contributi
Ottimo, sei riuscito a scovare il problema.
Ci mette così tanto perché quella view contiene molti tag?

Se pensi che sia una soluzione valida, modifica il tuo .csproj per precompilare le view, in modo che non debba essere fatto just-in-time.
https://scottsauber.com/2017/03/10/pre-compiling-razor-views-in-asp-net-core-with-csprojs/

ciao,
Moreno

Enjoy learning and just keep making
47 messaggi dal 12 agosto 2009
Grazie.
Comunque quest'articolo è migliore!

http://dotnetthoughts.net/compile-your-aspnet-core-mvc-views/
Modificato da eomer1975 il 16 giugno 2017 08.55 -

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.