Extremely strange problem - download speeds different in diff directories

Saeven

Verified User
Joined
Jun 29, 2003
Messages
76
I've a problem that I can't pinpoint, and was hoping that someone could bounce some ideas off of me.

I'm getting different download (server upload) speeds based on where a file is found on the server, and how it is accessed. These directories are all on a same drive, though operated by different vhosts.


affected area:
The affected space/file is:

/home/auracle/public_html/bigfile.tar.gz

If I access the file directly via its site, http://xxxx.com/bigfile.tar.gz, I get a 35k download speed, consistently. Strangely, if I access it via the userdir tilde mechanism, http://1.2.3.4/~auracle/bigfile.tar.gz I get a rapid download speed.


...otherwise:

If I place it in a different directory that is operated by a separate user, accessing the file via any means yields fast download speeds.


what I've done/tried:

I've disabled mod_throttle from /etc/httpd/conf/httpd.conf, which I understood would be the only means to throttle vhost upload speed. Further, accessing user auracle's space by IP, yields the same (bad) download speeds, so this mustn't be DNS related. Not sure if this is noteworthy, but the affected user space, is on an IP that differs from the primary IP. The tilde operator would still indicate that the inherent throttling is being done based on username alone however (since I understand that tilde access bypasses bandwidth measures?).

I'm at a bit of a loss past this point, and so any help is appreciated. Is this an elusive DA setting somewhere?

Kind regards.
Alexandre
 
Last edited:
Hello,

DA has no throttling enabled anywhere in any program.
If there is thottling going on, my only guess is if mod_throttle is present, it's defaulting to on in certain situations.

Test with the module not being loaded at all to see if that changes anything.
ie: disable the LoadModule option for it.

Nothing else really comes to mind.

John
 
Hi,

Thanks for the response, however, this has already been done as written above. I've commented out anything to do with mod_throttle from httpd.conf, and have restarted the webserver.

Do you believe this could instead be related to the fact that this domain is on a separate IP address?

Regards.
Alexandre
 
Yes, the IP addresses could cause it as well.
If they're using different gateways, that could change all the hardware being used by the datacenter, thus changing the speed.

John
 
~username was about 170k/s
without, it was about 40k/s

Try testing with ftp via the different IPs to see if it's apache related or not.
Also, try putting the file in /var/www/html/squirrelmail/zo.tar.gz and downloaded it from all the different IPs to see if you get any speed change with the consistent virtualhost.

Since the IPs are both very close to each other, they're very likely on the same subnet (same gateway). I did a traceroute to both IPs and they showed the same path (although, I couldn't ping the last machine beforey you server), I'm still assuming it's the same machine.

John
 
Indeed 2 of our IPs are slow! .45 and .46. I've no idea how Apache could exhibit this type of slowdown based on IP..
 
Ask your datacenter to check the routing on those two IP's ... if they're being used for other purposes (nameservers, etc) that might exhibit the speed impediment.


I'm assuming 1.2.3.4 isn't your actual IP ? :) Couldn't test without it
 
The affected IPs are:

72.232.186.45 and 72.232.186.46

Thanks for the help!
Alex
 
[root@www58 input]# host 72.232.186.45
45.186.232.72.in-addr.arpa domain name pointer 45.186.232.72.static.reverse.layeredtech.com.
[root@www58 input]# host 72.232.186.46
46.186.232.72.in-addr.arpa domain name pointer auraclesupport.com.
[root@www58 ~]# ping 72.232.186.46
PING 72.232.186.46 (72.232.186.46) 56(84) bytes of data.
64 bytes from 72.232.186.46: icmp_seq=0 ttl=54 time=53.2 ms
64 bytes from 72.232.186.46: icmp_seq=1 ttl=54 time=53.4 ms
64 bytes from 72.232.186.46: icmp_seq=2 ttl=54 time=53.3 ms
64 bytes from 72.232.186.46: icmp_seq=3 ttl=54 time=53.3 ms
64 bytes from 72.232.186.46: icmp_seq=4 ttl=54 time=53.4 ms
64 bytes from 72.232.186.46: icmp_seq=5 ttl=54 time=53.2 ms
64 bytes from 72.232.186.46: icmp_seq=6 ttl=54 time=53.1 ms
64 bytes from 72.232.186.46: icmp_seq=7 ttl=54 time=53.2 ms
64 bytes from 72.232.186.46: icmp_seq=8 ttl=54 time=53.4 ms
64 bytes from 72.232.186.46: icmp_seq=9 ttl=54 time=53.3 ms
64 bytes from 72.232.186.46: icmp_seq=10 ttl=54 time=53.4 ms

--- 72.232.186.46 ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 10017ms
rtt min/avg/max/mdev = 53.156/53.331/53.497/0.243 ms, pipe 2
[root@www58 ~]# ping 72.232.186.45
PING 72.232.186.45 (72.232.186.45) 56(84) bytes of data.
64 bytes from 72.232.186.45: icmp_seq=0 ttl=54 time=40.6 ms
64 bytes from 72.232.186.45: icmp_seq=1 ttl=54 time=39.8 ms
64 bytes from 72.232.186.45: icmp_seq=2 ttl=54 time=39.9 ms
64 bytes from 72.232.186.45: icmp_seq=3 ttl=54 time=40.2 ms
64 bytes from 72.232.186.45: icmp_seq=4 ttl=54 time=40.8 ms
64 bytes from 72.232.186.45: icmp_seq=5 ttl=54 time=40.1 ms
64 bytes from 72.232.186.45: icmp_seq=6 ttl=54 time=40.1 ms
64 bytes from 72.232.186.45: icmp_seq=7 ttl=54 time=40.1 ms
64 bytes from 72.232.186.45: icmp_seq=8 ttl=54 time=40.5 ms

--- 72.232.186.45 ping statistics ---
9 packets transmitted, 9 received, 0% packet loss, time 8012ms
rtt min/avg/max/mdev = 39.864/40.274/40.827/0.318 ms, pipe 2



8 dcr2-so-7-2-0.Atlanta.savvis.net (204.70.192.57) 50.212 ms ae-4-4.ebr2.Atlanta2.Level3.net (4.69.133.10) 17.970 ms dcr2-so-7-2-0.Atlanta.savvis.net (204.70.192.57) 42.393 ms
MPLS Label=377056 CoS=5 TTL=1 S=0
9 ae-1-100.ebr1.Atlanta2.Level3.net (4.69.132.33) 30.390 ms 30.820 ms dcr2-so-2-0-0.dallas.savvis.net (204.70.192.70) 47.059 ms
10 dcr1-so-6-0-0.dallas.savvis.net (204.70.192.49) 47.117 ms ae-3.ebr1.Dallas1.Level3.net (4.69.132.81) 42.720 ms 42.341 ms
11 dpr1-ge-4-0-0.dallasequinix.savvis.net (204.70.196.30) 47.140 ms ae-11-51.car1.Dallas1.Level3.net (4.68.122.13) 39.845 ms dpr1-ge-4-0-0.dallasequinix.savvis.net (204.70.196.30) 47.104 ms
12 aer1-ge-5-4.dallasequinix.savvis.net (204.70.194.38) 47.138 ms DATABANK-HO.car1.Dallas1.Level3.net (4.71.12.250) 39.386 ms aer1-ge-3-4.dallasequinix.savvis.net (204.70.194.34) 48.109 ms
13 lt-pod2b.lt.com (63.164.96.238) 39.543 ms 39.021 ms 208.175.175.66 (208.175.175.66) 52.217 ms
14 * lt-pod1a.lt.com (63.164.96.230) 53.306 ms 52.417 ms
15 45.186.232.72.static.reverse.layeredtech.com (72.232.186.45) 40.060 ms 39.936 ms 53.251 ms

and

6 4.68.111.9 (4.68.111.9) 2.029 ms 1.833 ms cpr2-pos-14-1.VirginiaEquinix.savvis.net (208.173.50.249) 28.007 ms
7 ae-23-23.car2.Miami1.Level3.net (4.69.133.21) 17.830 ms bcs1-so-3-3-0.Washington.savvis.net (206.24.238.97) 28.354 ms 28.723 ms
8 ae-4-4.ebr2.Atlanta2.Level3.net (4.69.133.10) 23.912 ms bcs2-so-7-0-0.Washington.savvis.net (204.70.192.34) 28.626 ms ae-4-4.ebr2.Atlanta2.Level3.net (4.69.133.10) 23.523 ms
9 ae-1-100.ebr1.Atlanta2.Level3.net (4.69.132.33) 25.104 ms dcr2-so-7-2-0.Atlanta.savvis.net (204.70.192.57) 42.512 ms dcr1-as1.dallas.savvis.net (204.70.194.178) 47.144 ms
10 ae-3.ebr1.Dallas1.Level3.net (4.69.132.81) 39.490 ms 39.311 ms dpr1-ge-4-0-0.dallasequinix.savvis.net (204.70.196.30) 47.154 ms
11 ae-11-53.car1.Dallas1.Level3.net (4.68.122.77) 38.351 ms aer1-ge-5-4.dallasequinix.savvis.net (204.70.194.38) 47.062 ms dpr1-so-0-0-0.dallasequinix.savvis.net (204.70.193.213) 47.023 ms
12 DATABANK-HO.car1.Dallas1.Level3.net (4.71.12.250) 39.337 ms 208.175.175.66 (208.175.175.66) 52.134 ms DATABANK-HO.car1.Dallas1.Level3.net (4.71.12.250) 39.624 ms
13 lt-pod2a.lt.com (63.164.96.226) 39.944 ms lt-pod1b.lt.com (63.164.96.234) 53.122 ms lt-pod2a.lt.com (63.164.96.226) 39.613 ms
14 * lt-pod1b.lt.com (63.164.96.234) 55.685 ms *
15 auraclesupport.com (72.232.186.46) 40.011 ms * 53.467 ms

There's a TON of latency in the Savvis network

I had a ton of issues with LayeredTech while we had servers there - all related to network performance - unfortunately, they weren't real willing to help troubleshoot as they're just reseller of empty/unused datacenter space.
 
looking back on those traceroutes, I find it very strange that there's different paths to each IP when they're in the same netblock.
 
I agree. All roads seem to lead to pod 2b, which I heard was an 'affected' pod though another soul on WHT; their support staff weren't even able to fess up to that issue from the get go. Two days later, still no response from them.. I'm not with LayeredTech directly, I'm with ZipSupport - and have 3 dedicated servers there.

We have some XServs in house, and will likely prep them and ship them out to a colo facility in Montreal nearby. I don't have any faith that Zipservers, or Layered tech will be able to rectify this.
 
Back
Top