Many modern applications rely on a database back-end, and for
those building for the Microsoft stack, SQL Server is the data layer of choice.
While in many cases the performance
of an application will be CPU-bound, often bottlenecks turn out to lie with
the application’s database interaction. This makes understanding the code’s SQL
activity vital for getting a hold on its performance.
One approach
used in the past has been to run the SQL Server Profiler at the same time as a
separate performance
profiler. This lets you understand code performance and look at SQL
activity separately, but understanding how the two are related can be difficult
and time-consuming. Sometimes slow or repeated queries are OK and don’t need
optimizing, but it all depends on the context in which whose queries were run.
Profiling Cubed
in ANTS
Performance Profiler builds SQL profiling into the same performance
profiler used for analyzing .NET code performance. Results can be compared side
by side, with SQL and code performance data automatically matched up against
each other on the interactive timeline.
Why would you
want SQL data in your code profiler?
Let’s look at an
example. The Beer House is an ASP.NET website using SQL Server as the data
layer. After attaching ANTS
Performance Profiler, detailed performance data is collected. Using the
interactive timeline, we can select any period to analyze code performance,
drilling down to view line-level timing data for any method. While this
approach is immensely useful for finding CPU-related slowdowns, it is less
helpful when the database is the bottleneck. In Figure 1, the btnVote_Click()
method is taking a long time to run but, after looking at the timing in the
source code window, this doesn’t seem to be because of the performance of the
code itself.
Figure 1. Code performance data, including line-level timing
After selecting
btnVote_Click(), and switching to the SQL Server data tab, we can see all
database activity on the local server for that same timespan. We can examine
which queries were run and get timing information and the number of rows
returned. This helps identify occasions where queries are being run
unnecessarily, often to re-fetch data which might better have been cached, or
where the same query is run multiple times in quick succession by mistake.
Figure 2. Detailed SQL activity for the selected timespan
To see SQL
profiling in action, watch this short video.
SQL profiling is
part of Profiling Cubed in ANTS
Performance Profiler, which brings together SQL, File I/O, and .NET code
profiling into the same tool for the most complete understanding of your
application’s performance.
Learn more about
Profiling
Cubed, or download
you free 14-day trial.
