Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a network traffic question, that I may get a lot of answers for. At work, I'm VPNing to a client's internal network where they have their stage SQL database. Every time I stage development (fixes/enhancements), I like to do a round of quick QA. When I run SQL queries in SQL Server Management Studio, things don't seem slow. But when I run their web application with the stage version of the web.config by using my local build, the lag is VERY slow when compared to using our company's dev SQL database web.config. file.

To give you a comparison, I start counting 1-1000, 2-1000, etc.. for one particular page. It takes 1.5 seconds to load the page with our dev web.config. But when using the stage web.config, I counted slightly longer than 8 seconds. I'm starting to move the application modules to using AJAX so I see some improvements on those pages, but the pages still have to load. So this really slows down my testing if I release a large package of updates.

If you can recommend some tools of diagnosing this slowness/lag, that's what I'm interested in. Also, if you can describe how I can troubleshoot it, that's what I'm looking for. I'm an .NET application developer, not a network administrator, so I wouldn't know where to begin on this one.


Clarification from above (5/23/2011 update):


Apparently, SQL Server Management Studio is also slow, so it's definitely the SQL connection across the networks. I did a quick ping on my local box when VPN'ed to the network where the *.234 Windows Server 2008 box sits. I then did another one from a different machine on the same network as *.235. So maybe there is no answer to this. They're using a T1 line, so could that be the issue. These times from the ping are extremely different.

On Remote Desktop on different machine, but different network machine. Pinging from same network as *.234 box:


Pinging with 32 bytes of data:

Reply from bytes=32 time<1ms TTL=128

Reply from bytes=32 time<1ms TTL=128

Reply from bytes=32 time<1ms TTL=128

Reply from bytes=32 time<1ms TTL=128

Ping statistics for Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms


On Local machine when VPN'ed to machine I'm pinging. Pinging from different network as *.234 box.


Pinging with 32 bytes of data:

Reply from bytes=32 time=856ms TTL=127

Reply from bytes=32 time=717ms TTL=127

Reply from bytes=32 time=561ms TTL=127

Reply from bytes=32 time=708ms TTL=127

Ping statistics for Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 561ms, Maximum = 856ms, Average = 710ms


share|improve this question

migrated from May 25 '11 at 13:25

This question came from our site for professional and enthusiast programmers.

up vote 0 down vote accepted

When you use remote desktop, only the screen updates are being sent to your PC, so the traffic going across the VPN is minimal. In that scenario, the database call you are making from Remote Desktop TO SQL Server is actually happening on the local network on the other side of the VPN. Your machine is just getting the Remote Desktop screen changes.

When you contact the site through your Local Browser, you are pulling the entire result set across the VPN, which is much more data than your Remote Desktop session (remote desktop is pretty efficient and runs at something like 2-10kbps, depending on your settings).

The only way to speed things up in this case would be:

  1. Get a faster connection so the VPN is quicker (or a direct connection where no VPN is required).
  2. Create a Local copy of the WebServer/Database and run against that system.
  3. Try optimizing your queries so that you are pulling as little data across the VPN as possible.

It's all an issue of bandwidth. Unless you are willing to invest serious money in a fast network connection between you and the remote host, you're going to have a hard time reaching speeds anywhere in the ballpark of what a LAN can do.

share|improve this answer
Thanks for the answer! – MacGyver May 25 '11 at 15:25

When you run a query in SQL management studio you are performing a single round-trip. You are only experiencing the increase in network latency once (say, ~500ms).

In your application, you are likely performing many queries; each one experiencing the same latency in serial. So if your application does 10 queries (or perhaps has some form of master-detail querying going on), you'll soon clock up many extra seconds in response time.

share|improve this answer
Hi Steve, I'd give you a point, but I'm too new to stack overflow. Thanks for your information. – MacGyver May 25 '11 at 15:23

That's great information about performing many queries, but let me give you a little more information? I'm still a bit confused on this. I found out something very interesting yesterday AND SO SIMPLE. Forget the scenarios of the web.configs. When I do a remote desktop and access the URL in the remote desktop (which is a machine on that network hosting the application and SQL server) it's VERY QUICK (<1ms) for each page load. But when I connect via a web browser on my local machine, it's VERY SLOW (500+ms). I'm VPN'ed in both cases. My workaround for my issue is to use remote desktop. In this new scenario, I'm hosting the web application on the remote server on the network where I'm remoting into. Here's a simple question. Why is the Remote Desktop so quick? There's GOT to be a way to mimic that on my local machine. Why would doing a remote desktop connection (locally) and opening a web browser locally be any different than looking at the site on my local machine??

On a side note to my first scenario... I also discovered that the registry setting "MaxPacketSize" decreased the ms in half. But things were still very slow.;en-us;244474#LetMeFixItMyselfAlways

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.