Comments on: SQL Server Management Studio: “Include Client Statistics” Button

By: Connecting to SQL Server – latency, part 1 « sqlconcept.com

Connecting to SQL Server – latency, part 1 « sqlconcept.com — Tue, 18 Dec 2012 11:04:36 +0000

[...] bytes sent to and from the client. For more details there is a good post on Client Statistics on BrentOzar.com by Jess Schultz Borland and I also wrote about it long ago on [...]

By: Steve Hall

Steve Hall — Tue, 11 Dec 2012 11:59:14 +0000

I use this tool when trying to improve the performance of Stored Procs, but concentrate on the ‘Average’ column with at least 6 runs of the code. There are invariably small variations in each execution, so I find that averaging the results out gives a better idea of any performance changes (I won’t say ‘improvements’ – it doesn’t always work like that!). Paste screen shots of these results into a document to show the changes, along with execution plans if possible. Then you can show the work done should there be any questions relating to it.

By: ross

ross — Mon, 10 Dec 2012 13:26:56 +0000

Thanks for clarifying guys

ross

By: Kevin Bullen

Kevin Bullen — Mon, 10 Dec 2012 12:27:05 +0000

Interesting. I have a lunch ‘n learn scheduled for later this week with our SQL developers and this is included as a demo. I use the ‘Bytes received from server’ column to demo why you should include NO COUNT in your procedures and triggers.

By: Feodor

Feodor — Mon, 10 Dec 2012 11:21:56 +0000

@ross The Client Statisics have very little to do with the SQL Server caching. Most of the Client Statistics functionality is related to the ‘big picture’ of client to database request and the data being sent back to the client. Whether the data is in cache of SQL Server or not it would not matter for the TDS packets nor for the ‘Bytes received from server’.
The only single place where you see the effect of the data being cached or not is ‘Wait time on server replies’.

Wait time on server replies – is the time in milliseconds between the last request packet which left the client and the first response packet which came back from the server to the client.

So in this case, if you have the data in chache, this time generally will be shorter in the consequtive runs. And if you clear the cache, then the time will be longer for the first execution, because the data needs to be cached. (Use SSDs and the time difference will be insignificant. )

Hope this helps.

Regards,
Feodor

By: Scott R.

Scott R. — Fri, 07 Dec 2012 22:43:10 +0000

Jes,

Great post and many thanks for this tip. I had not known about this feature before. It seems real useful and easy to use (one click!).

You can copy and paste the Client Statistics tab results into other docs, Excel, etc. – but not with the column headings (like in the query results tab) – not a biggie.

At first, I thought this might be a new SSMS feature in SQL 2012. Since then, I confirmed that the feature is present in SSMS for SQL 2008 R2, SQL 2008, and SQL 2005 as well. I also checked the Query Analyzer tool from SQL 2000 (predecessor of SSMS), and it has a simpler version of this feature (no tool bar icon – enable through the Query menu or keyboard shortcut, and only displays statistics for the most recent query run and the averages across runs versus displaying the history of multiple runs). So this feature has been around for quite a while! Who knew?

I Googled for prior hits on the topic and found some – but if you didn’t know to look for the specific topic (the feature name of “Client Statistics”) or hadn’t stumbled across it, you probably wouldn’t know it was there. Another case where covering a topic again can be a very good thing – thanks a second time.

Like Feodor, I think it would be great if there were similar tools / capabilities to track app level SQL client interactions. Another topic for another time.

Thanks again,

Scott R.

By: Jes Schultz Borland

Jes Schultz Borland — Fri, 07 Dec 2012 19:56:48 +0000

You will not always see a reduction in “Bytes received from server” or “TDS packets received from server”, even if the exact same query us run multiple times.

By: Something for the Weekend - SQL Server Links 06/12/12

Something for the Weekend - SQL Server Links 06/12/12 — Fri, 07 Dec 2012 19:50:10 +0000

[...] SQL Server Management Studio: “Include Client Statistics” Button - SSMS tools for performance tuning from Jes Borland (Blog|Twitter). Good call, as this measuring tool often gets overlooked. [...]

By: Feodor

Feodor — Fri, 07 Dec 2012 16:30:56 +0000

Yes, this is a great post!
I like using Client statistics when developing complex logic queries and procedures in SQL Server.

The Client Statistics kinda give an insight on what is going on beyond the SQL Server internals, i.e. TDS packets, network volumes transferred etc.

Recently I wrote an article on the ‘big picture’ topic, which explains more in detail the full cycle of the workload which goes to and from SQL Server. The article can be read here: http://www.simple-talk.com/sql/database-administration/how-come-the-hourglass-why-database-applications-slow-down.-/

There is one limitation of the Client Statistics in Management Studio, though. It only measures the workload of a query from Management Studio to the database engine. There is no way for them to measure the actual client statistics of an application. It would be so nice if there was a tool which could account and aggregate the TDS and network traffic in a similar way from the application perspective, don’t you think?

By: Golam Kabir

Golam Kabir — Fri, 07 Dec 2012 15:20:22 +0000

This is a good tip. Keep writing please.