NuovoRelico, gestore HTTP asincrono e AcquireRequestState

Question

Ho un problema con un gestore asincrono nell'app web ASP.NET distribuita. In primo luogo mi permetta di spiegare un caso d'uso:

• applicazione utilizza IIS 8 su win 2012 macchina con .NET Framework 4.5.2

• applicazione ha disattivato i moduli di sessione e di autenticazione tramite web.config come questo

   <system.webServer> 
       .... 
       <modules> 
        <remove name="WindowsAuthentication" /> 
        <remove name="Session" /> 
        <remove name="FormsAuthentication" /> 
       </modules> 
      </system.webServer> 
  

• applicazione utilizza gestore web asincrone personalizzato per soddisfare la richiesta specifica

• applicazione ha un traffico molto pesante (circa 50k richieste al minuto per server, del gestore async ha ab out 10k richieste al minuto per server tutti monitorati da NewRelic)
• applicazione è distribuita tramite diversi processi w3wp (2 processi w3wp) e più server virtuali (circa 10 server)
• applicazione ha elevata quantità di connessioni

Tutte le normali (richieste di sincronizzazione) funzionano bene ma la richiesta asincrona che fa un po 'più di lavoro (è per questo che usiamo richiesta asincrona) è spesso lenta ma NewRelic segnala che è lento a causa di "AcquireRequestState". Ora ho cercato su google e stack overflow e questo evento è collegato alla creazione di una sessione, ma abbiamo sessioni disabilitate in web.config. Qualcuno sa cos'altro potrebbe fare "AcquireRequestState"? Ci manca qualche posto per rimuovere lo stato della sessione? Aggiungendo che da web.config per machine.config non ha fatto nulla ...

Ecco un frammento da una richiesta in NewRelic:

**Slowest components Count Duration  % ** 
    AcquireRequestState 1 12,600 ms 100% --> WTF? 
    ExecuteRequestHandler 1 5.01 ms  0% 
    Integrated Pipeline 1 0.334 ms 0% 
    UpdateRequestCache  1 0.3 ms  0% 
    EndRequest    1 0.168 ms 0% 
    AuthenticateRequest 1 0.161 ms 0% 
    Total time     12,600 ms 100% 

EDIT: ho <sessionState mode="Off" /> in web.config (<system.web> sezione) quindi non è così.

Answer 1

AcquireRequestState viene utilizzato anche da Profile Module. Hai provato a disabilitarlo?

<modules> 
    <remove others unwanted modules... /> 
    <remove name="Profile" /> 
</modules> 

Answer 2

Ho esaminato questo perché avevamo problemi simili, ho trovato questo forum post, la risposta che è interessante è questo:

Purtroppo, la questione non è così semplice come girare sessionState off. In effetti, una delle frasi chiave quando si descrivono le sfide con AcquireRequestState è la frase, ad esempio, lo stato della sessione quando si verifica quando questo evento viene generato. Nel scavare più a fondo in questo (in realtà guardando il sorgente .NET) possiamo vedere che questo viene chiamato quando viene eseguito un EventHandler o viene creato un oggetto RequestNotification. Oserei dire che ci sono altri metodi e/o eventi che, quando chiamati, genereranno un evento AcquireRequestState. Rintracciarli tutti rappresenta qualcosa di una lotta. Sembra che questo non sia qualcosa di molto al di fuori delle discussioni sullo stato della sessione più normalizzate. Il luogo più comune in cui vediamo questo evento generato è sicuramente correlato alla gestione dello stato della sessione. Ma ci sono ovviamente degli outlier in cui questi eventi possono ancora essere sollevati. Può anche essere chiamato direttamente dal codice dell'applicazione. La cosa con cui l'agente è alle prese è che può identificare l'evento, ma raramente la fonte. Quando viene generato come parte della pipeline ASP, l'unica notifica ricevuta dall'agente è che questo è un segmento della transazione. L'origine, oi metodi eseguiti all'interno dell'evento, sono qualcosa che l'agente raramente sta strumentando di default. Vorrei poter offrire più informazioni per voi su questo. Ci sono molte parti mobili all'interno di a.Applicazione NET, alcuni dei quali riguardano il sistema operativo stesso, IIS, la versione di .NET, indipendentemente dal fatto che i metodi siano asincroni, impostazioni del pool di applicazioni, modalità di esecuzione, permessi, ecc. Mentre non voglio aprire un secondo può di worms qui, questo harkens al problema con la mancanza di tracce di stack per 500 errori. L'agente fornisce una traccia di stack quando viene offerta e/o disponibile. Dove la traccia dello stack, se ne esiste uno, si verifica all'interno della pipeline ASP è estremamente importante. A volte si verifica prima che venga eseguito qualsiasi codice effettivo dell'applicazione. In tali casi, l'errore viene segnalato all'applicazione, che a sua volta consente all'agente .NET di visualizzare e segnalare che si è verificato un errore, ma non vengono forniti altri dettagli. L'agente vede semplicemente che è successo e riporta quante più informazioni possibili. Oltre a ciò l'agente non ha semplicemente ulteriori dettagli che può offrire.

Abbiamo rinunciato, quindi sarei interessato a sapere se lo capisci!