views:

165

answers:

3

We have a dev server running C# and talking to SQL server on the same machine.

We have another server running the same code and talking to SQL server on another machine.

A job does 60,000 reads (that is it calls a stored procedure 60,000 times - each read returns one row).

The job runs in 1/40th of the time on the first server compared to it running on the second server.

We're already looking at the 'internal' differences between the two SQL Servers (fragmentation, tempdb, memory etc) but what's a good way to determine how much slower the second config is simply because it has to go over the network ?

[rather confusingly I found a 'SQL Server Ping' tool but it doesn't actually attempt any timing measurement which, as far as I can see, is what we need]

A: 

SQL Server ships with the Profiler utility. This will tell you what the execution time of your query is on each of your SQL Server instances. Note any discrepencies. Whatever time (in the ExecutionTime column) can not be accounted for here is transmission time... or client display time. Perhaps your client machine takes longer to render the results, or compute the results.

Boo
Thanks for your reply. I'm not 100% sure I understand it though. When you say 'look for any discrepancies' do you mean compare the times for a given action as shown by Profiler on both database servers ? I must confess I hadn't thought to try that. In looking at current profiler results there's already significant variance across the 60,000 calls to the SP so i'm not sure how much information I could extract from that. However as I say I haven't tried it and perhaps I should. What I'd really like is just a tool to measure how long a packet is taking to get to and from the db server.
southof40
You got it in one. I did indeed mean to look for differences in execution times.Though if all you want is a tool to measure how long it takes a packet to travel to and from the db server, might I suggest the venerable ping.exe.
Boo
I did try ping.exe (and the ping times are effectively zero) but I wasn't sure whether SQL Server itself might impose an overhead in receiving requests via the network. I'll just repeat here what I just in a downpage comment ... What I was hoping to find was a clientside tool which would watch the packets coming and going from SQL Server and determine how much time was spent 'on the network' . This may be too much to ask but it's what I was after ;-)
southof40
I forgot to say ... thanks for your comments I appreciate them.
southof40
I'm glad Brent chimed in. I learned something new. :)
Boo
A: 

What results are you expecting? Running everything on one machine vs over a network will certainly give you different timings. Your biggest timing difference will be the network throughput. You need to communicate to the networked server both ways.

If you can set NOCOUNT to on, this will help in less network traffic.

Dwight T
Maybe it's best if I give an example of what I was interested in.If in the networked situation (the second one I described) I found that each execution of the SP involved 25ms of Network overhead then for 60,000 executions I can immediately expect the process to take 1500 seconds longer than the nonnetworked situation.What I was hoping to find was a clientside tool which would watch the packets coming and going from SQL Server and determine how much time was spent 'on the network' . This may be too much to ask but it's what I was after ;-)
southof40
So busy answering I forgot to thank you for your comment.
southof40
I've used the SQLQueryStress program in the past. Not sure it is quite what you are looking for.http://www.datamanipulation.net/SQLQueryStress/
Dwight T
That's good - I've never seen SQLQueryStress before I'll give it a go. Thanks.
southof40
A: 

Open SQL Server Management Server on the remote machine. Start a new query. Click Query, Include Client Statistics. Run your stored procedure. In the Client Statistics tab of the results, you'll see some basic information about how many packets were sent back & forth over the network. My guess is that for one read, you're not going to see that much overhead.

To get a better idea, I'd try doing a plain select of 60,000 records (since you said it's returning 60,000 records one by one) over the network from your remote machine. Again, that doesn't give you an idea of the stored procedure overhead, but it'll give you a quick seat-of-the-pants idea of the network speed between machines.

Brent Ozar
That's great somehow I'd never noticed this within Management Studio but I think it's pretty close to what I was looking for I'll give it a go.
southof40