I'm looking into a performance of a login page taking 10-13 seconds to load. I'm using a DEMO database to test the performance and tweak to see any improvement. I'm using SQL Profiler to capture what is going on during the login and see what I can change. However, I'm noticing a few oddities.
- If I store to table the "duration" column in profiler is [n]*1000
compared to what is on the profiler GUI. (ie. GUI Windows shows
"exec proc1" and duration 50, but in the SQL trace table "exec
proc1" shows 50000. - If I add up all the duration values they are
not even 1/10th of the time the page takes to load. (I know profiler
will slow down the page load, but even without profiler a "fresh"
page load is 10 seconds+ on average and profiler duration (ms) add
up to roughly 1.1 second. - Also in between each run I am running CHECKPOINT, DBCC
DROPCLEANBUFFERS, DBCC FLUSHPROCINDB () to ensure each test is
"fresh".
Is there anything I'm doing wrong that would make these discrepancies occur? Is there anything you would recommend to change in my approach to solving this problem?
Best Answer
When you run DBCC DROPCLEANBUFFERS, DBCC FLUSHPROCINDB you require that the data is loaded into RAM and all plans are recompiled.
In a live system, you'd only this double whammy on startup or after heavy maintenance that evicted all data from cache and all plans were invalidated by a statistics update.
Your typical response time would be for the 2nd and subsequent calls.
On a really "cold" system your app in IIS would be unloaded too and would incur a CLR compile overhead