Response Time Analysis enables database administrators (DBAs) to measure time spent on query execution and, therefore, the impact on end-users.
The Response Time Analysis feature in SolarWinds® Database Performance Analyzer (DPA) is built to help you identify performance bottlenecks, pinpoint their root causes, and prioritize your actions based on the impact poor SQL Server performance tuning has on end users, so you can troubleshoot and deliver noticeable performance improvements.
Response Time Analysis does for DBAs what Application Performance Management (APM) does for IT—it identifies and measures an end-to-end process, starting with a query request from the end user and ending with a query response, including the time spent at each discrete step in between.
Response Time Analysis measures time for every wait type for each query, which lets you compare this data across queries. With an in-context view, you can prioritize efforts affecting the end user the most.
At the core of Response Time Analysis is the wait event or wait type, which refers to when a server process or thread must wait for an event to complete or resources to become available before being able to continue processing the query. Examples of this include moving data to a buffer, writing to disk, waiting on a lock, or writing a log file.
Typically, multiple wait events occur between a query request and response. If a query waits on a specific wait type more than usual, how can you find out? How do you know what’s “normal?” How can you find out why it’s waiting? And how do you fix it? That’s where Response Time Analysis comes in. SolarWinds DPA is built to establish wait time baselines and offer information on causes and potential fixes for high wait times.
Leverage real-time metrics—like queries, waits, and users—for effective SQL Server database performance tuning. SQL Server tuning advisors can direct you to end-user performance issues in urgent need of attention and help you identify opportunities across databases for more efficient SQL indexing.
DPA’s built-in analysis tools are designed to walk you through performance tuning steps, from assessing current query and wait-time behavior to performing in-depth query and index tuning and tracking the impact of your changes over time.
Got a query that’s burning CPU and you’re not sure why? AI Query Assist can take a look. Pull up the Query Details page for your SQL Server instance, point it at a problematic query and its execution plan, and SolarWinds AI rewrites the SQL for you—with a side-by-side comparison and specific tuning notes explaining what changed and why. No more staring at a plan for an hour, hoping something jumps out.
Do you find yourself asking…
Sometimes SQL Server performance problems are obvious — users are calling, pages are timing out, reports that used to run in seconds are taking minutes. Other times, the slowdown is subtle and builds quietly over weeks. Either way, a handful of signals can help you confirm what’s going on.
Check your wait stats first. Dynamic Management Views (DMVs) like sys.dm_exec_query_stats and sys.dm_os_wait_stats show which queries are consuming the most CPU, I/O, or elapsed time right now. If you don’t have a baseline, you’re guessing — so establish one early, before problems start. Other clear indicators include CPU or disk I/O consistently near capacity, a growing list of blocked sessions in Activity Monitor, batch request rates dropping while wait times climb, and application logs filling up with timeout errors.
SQL Server’s built-in Live Query Statistics feature, much like a profiler or extended events, can also show you real-time execution stats as a query runs — not after the fact. That’s useful for catching runaway queries before they finish, or confirming whether an index change actually helped. Tools like SolarWinds DPA go further by correlating wait data with historical trends, so you can see not just that something is slow, but why, and whether it’s getting worse over time.
Sometimes SQL Server performance problems are obvious — users are calling, pages are timing out, reports that used to run in seconds are taking minutes. Other times, the slowdown is subtle and builds quietly over weeks. Either way, a handful of signals can help you confirm what’s going on.
Check your wait stats first. Dynamic Management Views (DMVs) like sys.dm_exec_query_stats and sys.dm_os_wait_stats show which queries are consuming the most CPU, I/O, or elapsed time right now. If you don’t have a baseline, you’re guessing — so establish one early, before problems start. Other clear indicators include CPU or disk I/O consistently near capacity, a growing list of blocked sessions in Activity Monitor, batch request rates dropping while wait times climb, and application logs filling up with timeout errors.
SQL Server’s built-in Live Query Statistics feature, much like a profiler or extended events, can also show you real-time execution stats as a query runs — not after the fact. That’s useful for catching runaway queries before they finish, or confirming whether an index change actually helped. Tools like SolarWinds DPA go further by correlating wait data with historical trends, so you can see not just that something is slow, but why, and whether it’s getting worse over time.
Database Performance Analyzer for SQL Server