views:

130

answers:

6

I'm experiencing performance issues on my asp.net application. Sometimes it would take the client 30-40 seconds to execute a command, where as in sometimes it would take 3-4 seconds. I tried SQL Profiler and I don't see any problems. I was not able to replicate the issue on my side, under the same scenario when the client was trying.

I'm thinking that it might to do with session variables i'm using. I am using a lot of them to pass information within the page. However I Do not clear them.

If I clear them would it help? and if So Would this affect other users. Or does it only clear for that user?

Any help is appreciated.

A: 

Session and so session variables are user specific so clearing them will not affect other users.

keeping your session light will certainly help improving performance.

Vinay B R
A: 

Suggest that ASP.NET Session wouldn't impact your SQL Server roundtrip times in normal course of operating. Assuming nothing is being stored in session related to your data layer (i.e. static SqlConnection objects)

If you're seeing those long times (30-40 seconds), try to determine if performance is a gradual slowdown, or whether your SQL Server roundtrip times are sporradic.

Consider implementing logging to help determine a pattern. Start by writing to disk, one file per day/hour as you see appropriate.

  • start time of SQL command begin. Log the query/dataset/relevant info that you're passing.
  • end time of the SQL command.
 --- Executing statement SELECT * FROM Customers
 --- Start 08:55.44
 --- End   08:55.45 
 === Roundtrip was 1 second  SELECT * FROM Customers

After an hour/day/week, open the logs to look for "Roundtrip", and perhaps write a program to parse these logs for you.

p.campbell
+1  A: 

There was a record locking problem in one of the stored procedures in the .NET 2.0 implementation of SQL Server-based session storage. It looks like MS incorporated the fix in the .NET 4.0 release.

Take a look here: http://sanjevsharma.blogspot.com/2008/03/improving-aspnet-session-state-database.html

I'm 99% sure you can run the 4.0 version of aspnet_regsql -ssadd and still run ASP.NET 2.0 against it. I remember doing a diff of the 2.0 vs. 4.0 SQL script and the above fix was the only real difference. MS' implementation of the fix was a little nicer than (and clearly based on) the link above.

scottt732
A: 

If the problem doesn't seem to be your database, you could try profiling your web app and see where the bottlenecks are. It's difficult to reproduce variable problems like you're seeing on production (4-40 second delays), but the results of how many method calls are happening and which ones consume the most execution time might provide a hint.

Some are mentioned in http://stackoverflow.com/questions/3927/what-are-some-good-net-profilers

Personally I'm a big fan of the EQATEC profiler.

Stefan Mohr
A: 

If you've got variability on that scale, you could very well be looking at some sort of locking or contention issue. Depending on timing, and what else is going on when you profile, you might not see a SQL locking issue if that's what it is. Try monitoring lock metrics in perfmon to see if there's anything suspicious there, and give some thought to what else in the system could be causing any sort of locking or latency wait time.

D. Lambert
A: 

Have you tried enabling ASP.NET trace logging and viewing the load times in the call stack? I've used this quite a bit to diagnose bottlenecking in ASP.NET performance. If you're unfamiliar with trace.axd, you can enable it via your configuration file

<trace enabled="true" />

Enabling this configuration setting will allow you to browse to trace.axd at the root of your site and view the last 10 transactions in detail. You can enable a larger result set, rolling result sets, and a bunch of other nifty tracing options through that trace element.

Soundsoldier