October 14, 2008 at 7:33 am
I have a server running SQL2005. I developed an application using SpatialWare which pulls all of the maps, etc out of the sql database. When used inside the building I can get a throughput of 33mbits/sec outbound. When we try to access it from outside the building I am getting 4mbits/sec outbound.
The part that is really bothering me is the inbound side. We get 33mbits/sec inbound inside the network.
But if you try the same from outside you get 64k/sec. It doesn't seem to be a bandwidth issue.
I can use the same server and ftp a file to it at 10mbits/sec.
We recently made an exact copy of the server and placed it in colocation to rule out our network.
I am getting the same issues there. I used the easyloader tool to load up a map into sql.
Inside the building it will load the 15,000 records in 10 seconds at 5.1mbits/sec.
Outside the building it loaded the same 15,000 records in 30 minutes at 64k/sec.
Does it have something with the protocols that SQL Server uses? Do I need to saturate the ds3 pipe somehow to get a faster throughput? Can I set a push flag somehow?
Can someone please help me.
Thanks
October 14, 2008 at 7:46 am
This sounds like an issue with your client-side IP.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
October 14, 2008 at 7:49 am
I'm going to have to go with not an SQL issue. Network or client machine or something related to that.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 14, 2008 at 7:55 am
The first thing I would check is a firewall and specifically firewall log.
October 14, 2008 at 8:07 am
We have tried multiple client machines. When used in the building they are fast. When used outside they are slow.
We have two servers on two different networks for testing and they are both behaving the same way.
Our network router blocks all ports except those that we give exceptions to. We opened it up for the sql ports and it didn't make a difference. So we put back the restrictions and we now use a SSH connection to Client to Server port forward. Basically the end user connects to our sql server using localhost:5555.
The configuration is extremely fast (up/down) when used inside the building. But outside I get the same 64k/sec up no matter if I use SSH or straight to SQL server. The down speed is fine. It's just the upload that is not working properly.
Is there a way to make a sql packet push? Or saturate the ds3 pipe so it sends data faster?
I think the reason it can push the data out faster is because it has 5 sql connections open to serve each one of the maps. On the upload side it only needs one connection to send the changed data to the server. So the data is not sent as fast.
On a 10/100 switch your bandwidth is there as soon as you open a connection. On a DS3 pipe you need to saturate the pipe somehow to achieve a higher speed. I just don't know how to saturate the pipe.
October 14, 2008 at 8:16 am
I guess I don't understand what method you are using to upload all this into the database. Are you using some sort of distributed transaction for all of it?
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
October 14, 2008 at 8:31 am
Tim Brandt (10/14/2008)
We have tried multiple client machines. When used in the building they are fast. When used outside they are slow.
Nobody said anything about client-side inside the building. This is a problem, either with your IP or with your in-house connectivity to your IP. One (or both) of these has been setup to give different classes of service based on protocol/port/context.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
October 14, 2008 at 9:17 am
Since we're talking straight network issues at this point - you might care to make sure that your frame sizes are compatible all of the way through. LAN traffic nowadays tends to use much larger frames than what most pipelines and/or firewalls are comfortable handling. Not setting it right up front results in a lot of bad sends (as the sending machine progressively dials down its window size to find one that will get all of the way through).
But still - none of this ultimately has anything to do with SQL Server itself.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 14, 2008 at 9:27 am
But still - none of this ultimately has anything to do with SQL Server itself.
SQL server is the only application I am having speed issues with. If I do a download via HTTP.
OR FTP a file to or from the servers the speed is there. ONLY having a speed issue when SQL Server
is involved.
I was hoping maybe someone here had dealt with this issue before.
October 14, 2008 at 10:21 am
Tim Brandt (10/14/2008)
But still - none of this ultimately has anything to do with SQL Server itself.
SQL server is the only application I am having speed issues with. If I do a download via HTTP. OR FTP a file to or from the servers the speed is there. ONLY having a speed issue when SQL Server is involved.
All that means is that the firewall/bridge/router/gateway/whatever that is responsible for this problem is port specific or protocol specific or packet-size specific or content specific in its behavior.
And yes, I have seen this before on many different applications, not just SQL Server. It always turns out to be network or IP configuration issues.
SQL Server does not have different network speeds for different activity, or addresses or whatever. Network boxes and configurations, on the other hand, have this kind of "class-based service levels" all over the place.
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply