Link to home
Start Free TrialLog in
Avatar of Techrunner
Techrunner

asked on

Slow SQL connection over MPLS

Hello Experts,

We recently bought a dedicated MPLS ( 100 Mbps up/down)  circuit between our Main and Branch Office.
We are experiencing an issue with a client connecting to SQL application
When we launch our application, it sends query to the application server on SQL port. The application username and password is launched after 30 seconds.
The transaction within the application is normal.
The ping latency between client and server is 4 ms.

Does anyone have any ideas what could be causing this issue?
Avatar of aleghart
aleghart
Flag of United States of America image

Try eliminating DNS as a possible culprit.
Can you map the application via IP address for testing?
If using hostname only , or even FQDN, you may be experiencing a lookup failure locally.  After the failure, your desktop may go to the next DNS server, finding the right host.
That might explain why subsequent transactions are not delayed, but only the first contact to the server is.

Another way to test (if you can't map to IP address):
Find the reference to the server (hostname or FQDN).
Ping this exactly as requested by the application.
Measure delay.
Launch application
See if delay is gone.
Avatar of Techrunner
Techrunner

ASKER

Hi,
The application is already mapped with an IP address, No FQDN is involved.
Active Directory credentials?  The DCs are called by FQDN.  Maybe try pinging the DCs listed for your site first.
Doesn't require active directory credentials.
Its SQL based application.
The only slowness when launching the application and it takes 30 seconds for the username and password screen to appear.
Avatar of robocat
It might be a good idea to use a packet sniffer to see what's going on (eg. wireshark). You can install this on the same client pc where the application runs.

This way you can see what is happening during these 30 seconds.
Hi,
Sorry I just forgot to mention something here that NAT ( Network Address Translation) is also involved, does that make any difference ?
NAT on the client side or on the server side? Please provide more details.
Hi,  Please find attached design for more explanation.
design.png
After sniffing the packet traces using wireshark, responses from SQL server side come with a delay approximately 0.02 seconds or more. however client sends the next query without waiting.

The link bandwidth is 100 Mbps ( Up/Down), and it is not use.

This issue is driving me crazy :)
So in the 30 seconds you're seeing a lot of requests going up and down the line?
Yes Sir
This is most likely a latency issue combined with lots of requests at startup of your application. 1500 requests with a latency of 0.02 seconds gives you 30 seconds.

This is a quite common issue when programmers write code that is not efficient enough for use over WAN networks.

Is this a commercial app or inhouse development?
Hi,
We have the same application used in other branches having 50 Mbps bandwidth but not facing any issue.

The problematic site has 100 Mbps WAN circuit, therefore it shouldn't be latency issue I suppose.
Is this a commercial app or inhouse development?
Commercial app
The bandwidth of a connection says nothing about latency. Even Gbit connections can have significant latency.

20ms response time might not seem much but it is significant if multiplied by a 1000 requests. Sadly, as this is a commercial app, there's probably no way to find out why the app needs to do so many requests even before logon.

We often resort to a remote desktop solution for use with SQL applications over the WAN. In this case, it would suffice to do this for your problematic site.
ASKER CERTIFIED SOLUTION
Avatar of Techrunner
Techrunner

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Curious:  Was the shared drive a hostname or FQDN?
How did actual IP work, if it was hiddent with NAT?

Trying to understand how you solved the problem.
Curious:  Was the shared drive a hostname or FQDN?

It was an IP, this path linked within DB with a real IP of application server. However the branch office can only access the application server using NATed IPs, therefore the real IP was not reachable
So within DB we can changed the path with Nated IP and it worked.
Please to close  this question as it was solved by author.