2010-09-26 22 views
5

Sto riscontrando problemi di prestazioni sulla mia applicazione asp.net. A volte il client impiega 30-40 secondi per eseguire un comando, dove a volte ci vogliono 3-4 secondi. Ho provato SQL Profiler e non vedo alcun problema. Non ero in grado di replicare il problema da parte mia, nello stesso scenario in cui il cliente stava provando.Prestazioni sessione ASP.NET

Sto pensando che potrebbe avere a che fare con le variabili di sessione che sto usando. Sto usando molti di loro per passare informazioni all'interno della pagina. Tuttavia non li svuoto.

Se li cancello sarebbe utile? e se così interesserebbe gli altri utenti. O è chiaro solo per quell'utente?

Qualsiasi aiuto è apprezzato.

+0

Potrebbe fornirci maggiori informazioni sul carico del server quando questo accade, inclusi l'utilizzo della CPU e l'utilizzo della memoria? Di solito cerco i deadlock delle risorse o i timeout quando le richieste iniziano improvvisamente a richiedere più di 30 secondi. – sisve

+2

Questi tipi di domande sono davvero difficili da rispondere. Com'è l'hardware? Quanti utenti di server web? Esattamente quanti dati in sessione (puoi quantificarli "molti di loro") per utente? Quanti utenti di SQL Server? Differenze nel throughput di piattaforme/hardware/rete e circa un milione di altri fattori (codice errato, architettura scadente, ora del giorno, bilanciamento del carico, memorizzazione nella cache, ecc.) Possono influire sulle prestazioni. Com'è l'ambiente? –

+0

Quale modalità di stato di sessione stai usando? cioè inproc, sqlserver o stateserver? Gli ultimi due useranno più risorse rispetto alle prime, anche se sono più resilienti. –

risposta

0

Sessione e quindi le variabili di sessione sono specifiche dell'utente in modo che la loro eliminazione non influenzi gli altri utenti.

mantenere la luce della sessione aiuterà sicuramente a migliorare le prestazioni.

0

Suggerire che la sessione ASP.NET non abbia alcun impatto sui tempi di round trip di SQL Server durante il normale funzionamento. Supponendo che nulla venga archiviato nella sessione correlata al livello dati (ad esempio oggetti SqlConnection statici)

Se osservi quei tempi lunghi (30-40 secondi), prova a determinare se le prestazioni sono un rallentamento graduale o se il tuo I tempi di andata e ritorno di SQL Server sono sporadici.

Considerare l'implementazione della registrazione per aiutare a determinare un modello. Inizia scrivendo su disco, un file al giorno/ora come ritieni appropriato.

  • ora di avvio del comando SQL. Registra la query/set di dati/informazioni rilevanti che stai passando.
  • ora di fine del comando SQL.
 
--- Executing statement SELECT * FROM Customers 
--- Start 08:55.44 
--- End 08:55.45 
=== Roundtrip was 1 second SELECT * FROM Customers 

Dopo un'ora/giorno/settimana, aprire i log alla ricerca di "andata e ritorno", e, forse, scrivere un programma per analizzare questi registri per voi.

1

Si è verificato un problema di blocco della registrazione in una delle procedure memorizzate nell'implementazione .NET 2.0 dell'archiviazione di sessione basata su SQL Server. Sembra che MS abbia incorporato la correzione nella versione .NET 4.0.

dare uno sguardo qui: http://sanjevsharma.blogspot.com/2008/03/improving-aspnet-session-state-database.html

Sono sicuro che il 99% è possibile eseguire la versione 4.0 di Aspnet_regsql -ssadd e ancora correre ASP.NET 2.0 contro di essa. Ricordo di aver fatto un diff dello script SQL 2.0 vs 4.0 e la correzione sopra era l'unica vera differenza. L'implementazione della correzione da parte di MS era un po 'più carina (e chiaramente basata sul link sopra).

0

Se il problema non sembra essere il vostro database, potete provare a profilare la vostra app Web e vedere dove sono i colli di bottiglia. È difficile riprodurre problemi variabili come quelli visualizzati durante la produzione (ritardi di 4-40 secondi), ma i risultati di quante chiamate di metodo stanno accadendo e quali consumano il maggior tempo di esecuzione potrebbero fornire un suggerimento.

Alcuni sono menzionati nella What Are Some Good .NET Profilers?

Personalmente sono un grande fan del profiler EQATEC.

0

Se si dispone di una variabilità su tale scala, è possibile che si tratti di un problema di blocco o di contesa. A seconda della tempistica e di cosa sta succedendo durante il profilo, potresti non vedere un problema di blocco SQL se è così. Prova a monitorare le metriche di blocco in perfmon per vedere se c'è qualcosa di sospetto lì, e riflettere su cosa altro nel sistema potrebbe causare qualsiasi tipo di tempo di attesa di blocco o latenza.

0

Hai provato a abilitare la registrazione di traccia ASP.NET e a visualizzare i tempi di caricamento nello stack di chiamate? Ho usato questo un po 'per diagnosticare il controllo in bottiglia nelle prestazioni di ASP.NET. Se si ha familiarità con trace.axd, è possibile attivare tramite il file di configurazione

<trace enabled="true" /> 

L'attivazione di questa impostazione di configurazione vi permetterà di navigare a trace.axd alla radice del tuo sito e visualizzare le ultime 10 transazioni in dettaglio. È possibile abilitare un set di risultati più ampio, set di risultati a rotazione e una serie di altre opzioni di traccia nifty attraverso tale elemento di traccia.