Poplar Proxies don't reach 3 meg speed - Page 4

downquark1 · 01-04-2005, 19:21

To be honest I'm wondering why this is getting so little attention. If people pay for faster speeds why are they complaining when they don't get them? Is is possible it's just the odd poplar and manchester proxy?

Chrysalis · 02-04-2005, 04:05

Quote:

Originally Posted by downquark1

To be honest I'm wondering why this is getting so little attention. If people pay for faster speeds why are they complaining when they don't get them? Is is possible it's just the odd poplar and manchester proxy?

Obviously not the case if you read my posts, guildford,nottingham and leicester also affected. The reason its got low attention is because when you browse the web and download small files it is unlikely the end user will notice that much, not to mention that I bet most of the time when people do ring up tech support they probably get told that its the server the other end not been able to send at the full speed.

mr-b · 02-04-2005, 14:16

Have any specific examples of consistently slow web server downloads through a certain proxy (or set of proxies) vs a faster download from the exact same server going via another proxy (or network) actually been reported to ntl? I certainly haven't seen any here.

I would think this is prolly the reason why it hasnt had any 'attention' - I would think that support would find it impossible to analyse a problem when it's just reported as "the proxies are slow/broken" and ppl do seem to have a tendency to blame them for everything under the sun ...

Rather like "When all you have is a hammer [selecting your proxy] - every problem looks like a nail [the proxy]."

downquark1 · 02-04-2005, 14:29

Quote:

Originally Posted by mr-b

Have any specific examples of consistently slow web server downloads through a certain proxy (or set of proxies) vs a faster download from the exact same server going via another proxy (or network) actually been reported to ntl? I certainly haven't seen any here.

I would think this is prolly the reason why it hasnt had any 'attention' - I would think that support would find it impossible to analyse a problem when it's just reported as "the proxies are slow/broken" and ppl do seem to have a tendency to blame them for everything under the sun ...

Rather like "When all you have is a hammer [selecting your proxy] - every problem looks like a nail [the proxy]."

Look here:

Quote:

Just posting more evidence:

I have 3 downloads coming from the same fileplanet server, the one going through my regular manchester proxy immediately went to 20KB. I then switched to the col-1 and started 2 more, those are coming through at 88KB and 112KB.

Ok instead of "my regular proxy" I mean the one it was automatically routed through.

We have said many times that downloading the same URL through colchester-1 is faster than the auto-routed method.
__________________

See screenshots

IanUK · 02-04-2005, 17:27

I also posted 2 specific examples - EasyNews and Fileplanet - so it seems a good place to start might be Fileplanet - as two of us have mentioned that one as being slow with specific proxies and speedier or full speed with other specific proxies, but to be honest I find I can choose almost any USA site and find it downloads files at half the speed compared to full expected 3 meg speed with specified proxies of Colchester or Hersham or Swansea.

Try Fileplanet with Poplar Proxies - then try Fileplanet with Colchester proxies for example.

Easynews have a trace here that includes a speed measurement.
http://www.easynews.com/slow/trace.phtml

cheers

Ian

ian@huth · 02-04-2005, 17:47

The proxies are designed to work most efficiently if customers do not specify a particular proxy but leave them to get on with their work. If too many customers, particularly top tier customers, specify the same proxy then it can cause congestion using that proxy.

The speed achievable through a proxy depends on whether that proxy has had to obtain the data from source or already has it cached by another customer having recently asked for the same data.

IanUK · 02-04-2005, 18:52

Quote:

The speed achievable through a proxy depends on whether that proxy has had to obtain the data from source or already has it cached by another customer having recently asked for the same data.

Sorry, but I just don't buy that as the answer to this particular problem, if that was the case then randomly chosing proxies would show speed differences all the time, but Poplar is *always* slow on virtually all USA sites and Colchester for example is *always* fast on virtually all USA sites.

If this problem depended on cached files/sites then it would be spread over all of them and it plainly isn't.

I NEVER get full speed from the USA sites I regularily visit using my default Poplar proxies (any of them it seems) - I ALWAYS get full speed using Colchester/Swansea or Hersham Proxies.

I'm not sure how much plainer I can put it

http://www.supernews.com/stats/active.txt as another example gives a speed of about 120-130k using Poplar default - Colchester gives 376k.

Cheers

Ian

mr-b · 02-04-2005, 18:58

Maybe I should have said more specific in my last post...

Anyway I carried out some testing on the actual example that was given in the first post of this thread.

I downloaded this same 1.5MB object from www.supernews.com several times:
- via my local transparently-redirected group of proxies (Bham)
- via specified proxies, both local and remote in different areas.
- via my work's VPN connection via a VPN server in the US

I downloaded the object using the free GNU uility 'wget' on XP: http://gnu.paradoxical.co.uk/software/wget/wget.html

It is a simple command line 'web get' tool which should eradicate any browser discrepancies. It can specify a proxy, indicate the object's download speed, and display the http headers which are useful in determining whether it's the same object and whether it's been obtained from cache. (Unfortunately I did have some small background file transfers going on which might explain some variance in the results, but it wasn't very significant.)

Results (long)

The speed for the first object fetch was broadly similar (70-100KB/s) for all locations, irrespective of whether it was from transparently redirected caches or manually specified - and the same for local vs remote. It was even slower via my US VPN connection (which does have to encrypt/decrypt and encapsulate every packet).
Then for any subsequent hits from the same cache, the object downloaded at full speed (300KB/s).

So from this admittedly quick and dirty test I can't see anything much different about any of the proxies that I tried, and it appears that www.supernews.com is doing rate limitation for every connection (fairly understandable given the site) - unless anyone can download this object at a significantly faster rate (and show that is hasn't been cached).

Full results:

In the below http headers, note that if the 'Age:' header is >= a few seconds then the object is a cache hit i.e. it has been served from the cache.
(http://rfc.net/rfc2616.html#s14.6)

#1 Transparently redirected via Bham cache group (Miss)

Destination is www.supernews.com - the network latency via ping seem to be about 200ms (so it's a US site).

D:\temp\wget>ping www.supernews.com

Pinging www.supernews.net [216.168.3.20] with 32 bytes of data:

Reply from 216.168.3.20: bytes=32 time=175ms TTL=107
Reply from 216.168.3.20: bytes=32 time=177ms TTL=107
Reply from 216.168.3.20: bytes=32 time=269ms TTL=107
Reply from 216.168.3.20: bytes=32 time=191ms TTL=107

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

#1 First object fetch via local transparent proxies (Bham)

D:\temp\wget>wget http://www.supernews.com/stats/active.txt
--14:21:23-- http://www.supernews.com/stats/active.txt
=> `active.txt'
Resolving www.supernews.com... 216.168.3.20
Connecting to www.supernews.com[216.168.3.20]:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1,442,929 [text/plain]

100%[====================================>] 1,442,929 94.32K/s ETA 00:00

14:21:40 (83.78 KB/s) - `active.txt' saved [1442929/1442929]

#2 Again (Hit)

D:\temp\wget>wget -S http://www.supernews.com/stats/active.txt
--14:26:20-- http://www.supernews.com/stats/active.txt
=> `active.txt.1'
Resolving www.supernews.com... 216.168.3.20
Connecting to www.supernews.com[216.168.3.20]:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 297
3 Accept-Ranges: bytes
4 Date: Sat, 02 Apr 2005 13:21:23 GMT
5 Content-Length: 1442929
6 Content-Type: text/plain
7 Connection: keep-alive
8 Proxy-Connection: keep-alive
9 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
10 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
11 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 240.05K/s ETA 00:00

14:26:25 (277.44 KB/s) - `active.txt.1' saved [1442929/1442929]

#3 Again (Hit)

D:\temp\wget>wget -S http://www.supernews.com/stats/active.txt
--14:32:10-- http://www.supernews.com/stats/active.txt
=> `active.txt.3'
Resolving www.supernews.com... 216.168.3.20
Connecting to www.supernews.com[216.168.3.20]:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 647
3 Accept-Ranges: bytes
4 Date: Sat, 02 Apr 2005 13:21:23 GMT
5 Content-Length: 1442929
6 Content-Type: text/plain
7 Connection: keep-alive
8 Proxy-Connection: keep-alive
9 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
10 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
11 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 313.85K/s ETA 00:00

14:32:15 (319.67 KB/s) - `active.txt.3' saved [1442929/1442929]

#4 Use Poplar-1 proxy (Miss)
>set http_proxy=popl-cache-1.server.ntli.net:8080

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--14:39:05-- http://www.supernews.com/stats/active.txt
=> `active.txt.4'
Resolving popl-cache-1.server.ntli.net... 62.255.64.4
Connecting to popl-cache-1.server.ntli.net[62.255.64.4]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 0
3 Date: Sat, 02 Apr 2005 13:39:07 GMT
4 Content-Length: 1442929
5 Content-Type: text/plain
6 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
7 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
8 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 120.91K/s ETA 00:00

14:39:20 (104.51 KB/s) - `active.txt.4' saved [1442929/1442929]

#5 Same again (Hit)

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--14:39:57-- http://www.supernews.com/stats/active.txt
=> `active.txt.5'
Resolving popl-cache-1.server.ntli.net... 62.255.64.4
Connecting to popl-cache-1.server.ntli.net[62.255.64.4]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 51
3 Accept-Ranges: bytes
4 Date: Sat, 02 Apr 2005 13:39:07 GMT
5 Content-Length: 1442929
6 Content-Type: text/plain
7 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
8 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
9 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 306.08K/s ETA 00:00

14:40:02 (306.26 KB/s) - `active.txt.5' saved [1442929/1442929]

#6 try from Poplar-cache-2 (Miss)

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--14:41:10-- http://www.supernews.com/stats/active.txt
=> `active.txt.6'
Resolving popl-cache-2.server.ntli.net... 62.255.64.5
Connecting to popl-cache-2.server.ntli.net[62.255.64.5]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 0
3 Date: Sat, 02 Apr 2005 13:41:11 GMT
4 Content-Length: 1442929
5 Content-Type: text/plain
6 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
7 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
8 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 121.03K/s ETA 00:00

14:41:23 (116.68 KB/s) - `active.txt.6' saved [1442929/1442929]

#7 try from local Bham-5 cache (Miss):

D:\temp\wget>set http_proxy=brhm-cache-5.server.ntli.net:8080

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--14:42:33-- http://www.supernews.com/stats/active.txt
=> `active.txt.7'
Resolving brhm-cache-5.server.ntli.net... 62.255.32.13
Connecting to brhm-cache-5.server.ntli.net[62.255.32.13]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 1
3 Date: Sat, 02 Apr 2005 13:42:34 GMT
4 Content-Length: 1442929
5 Content-Type: text/plain
6 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
7 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
8 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 71.01K/s ETA 00:00

14:42:51 (83.84 KB/s) - `active.txt.7' saved [1442929/1442929]

#8 local Bham-5 cache again (Hit)

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--14:47:37-- http://www.supernews.com/stats/active.txt
=> `active.txt.9'
Resolving brhm-cache-5.server.ntli.net... 62.255.32.13
Connecting to brhm-cache-5.server.ntli.net[62.255.32.13]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 304
3 Accept-Ranges: bytes
4 Date: Sat, 02 Apr 2005 13:42:34 GMT
5 Content-Length: 1442929
6 Content-Type: text/plain
7 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
8 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
9 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 319.13K/s ETA 00:00

14:47:41 (320.54 KB/s) - `active.txt.9' saved [1442929/1442929]

#9 From Manc-2 (Miss)

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--14:44:39-- http://www.supernews.com/stats/active.txt
=> `active.txt.8'
Resolving manc-cache-2.server.ntli.net... 62.252.192.5
Connecting to manc-cache-2.server.ntli.net[62.252.192.5]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 0
3 Date: Sat, 02 Apr 2005 13:44:41 GMT
4 Content-Length: 1442929
5 Content-Type: text/plain
6 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
7 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
8 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 104.05K/s ETA 00:00

14:44:54 (98.48 KB/s) - `active.txt.8' saved [1442929/1442929]

#10 local Bham-6 cache (Miss)

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--14:48:23-- http://www.supernews.com/stats/active.txt
=> `active.txt.10'
Resolving brhm-cache-6.server.ntli.net... 62.255.32.14
Connecting to brhm-cache-6.server.ntli.net[62.255.32.14]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 1
3 Date: Sat, 02 Apr 2005 13:48:25 GMT
4 Content-Length: 1442929
5 Content-Type: text/plain
6 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
7 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
8 ETag: "cb9610-160471-424de09b"

100%[====================================>] 1,442,929 91.69K/s ETA 00:00

14:48:42 (79.62 KB/s) - `active.txt.10' saved [1442929/1442929]

#11 - via work VPN (US connection)

D:\temp\wget>wget -S -Yoff http://www.supernews.com/stats/active.txt
--14:50:26-- http://www.supernews.com/stats/active.txt
=> `active.txt.11'
Resolving www.supernews.com... 216.168.3.20
Connecting to www.supernews.com[216.168.3.20]:80... connected.
HTTP request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Age: 0
3 Date: Sat, 02 Apr 2005 07:26:44 GMT
4 Content-Length: 1442929
5 Content-Type: text/plain
6 Connection: keep-alive
7 Proxy-Connection: keep-alive
8 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
9 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
10 ETag: "cb9610-160471-424de09b"
11 Via: 1.1 corpse (xxxxxxxxx)

100%[====================================>] 1,442,929 52.42K/s ETA 00:00

14:50:51 (59.17 KB/s) - `active.txt.11' saved [1442929/1442929]

mr-b · 02-04-2005, 19:47

I just tried a Colchester proxy - and it does seem faster on a miss:

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--19:40:37-- http://www.supernews.com/stats/active.txt
=> `active.txt.16'
Resolving colc-cache-3.server.ntli.net... 213.107.224.11
Connecting to colc-cache-3.server.ntli.net[213.107.224.11]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Date: Sat, 02 Apr 2005 18:40:40 GMT
3 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
4 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
5 ETag: "cb9610-160471-424de09b"
6 Accept-Ranges: bytes
7 Content-Length: 1442929
8 Content-Type: text/plain
9 Age: 1
10 Via: HTTP/1.1 ntl_site (Traffic-Server/5.2.4-59306 [cMsSfW])

100%[====================================>] 1,442,929 261.36K/s ETA 00:00

19:40:47 (163.81 KB/s) - `active.txt.16' saved [1442929/1442929]

But this is an Inktomi cache (others were Netapps) - so it might have had its RWIN tweaked higher.

So then I tried a Bromley one (also Inktomi) and it exhibits the same - but even faster!

D:\temp\wget>wget -S -Yon http://www.supernews.com/stats/active.txt
--19:46:05-- http://www.supernews.com/stats/active.txt
=> `active.txt.20'
Resolving cache2-bmly.server.ntli.net... 80.1.224.5
Connecting to cache2-bmly.server.ntli.net[80.1.224.5]:8080... connected.
Proxy request sent, awaiting response...
1 HTTP/1.0 200 OK
2 Date: Sat, 02 Apr 2005 18:46:07 GMT
3 Server: Apache/1.3.31 (Unix) DAV/1.0.3 mod_perl/1.29 mod_ssl/2.8.19 OpenSSL/0
.9.7d
4 Last-Modified: Sat, 02 Apr 2005 00:00:27 GMT
5 ETag: "cb9610-160471-424de09b"
6 Accept-Ranges: bytes
7 Content-Length: 1442929
8 Content-Type: text/plain
9 Age: 0
10 Via: HTTP/1.1 ntl_site (Traffic-Server/5.2.4-59306 [c sSf ])

100%[====================================>] 1,442,929 316.95K/s ETA 00:00

19:46:12 (265.17 KB/s) - `active.txt.20' saved [1442929/1442929]

So it is looking rather like the Inktomis have had their max RWIN size increased but not the Netapps.

IanUK · 02-04-2005, 20:00

Wow, thats some stats there

A bit more impressive than my DUMeter reading setup !

I can understand that if you are pulling in a cached file from one of the proxies, then you will get better speeds, but my own experience seems to suggest that the Poplar proxies are not caching *anything* from the USA (ie: virtually nothing goes above 150k) whereas the Colchester/Hersham/Swansea proxies cache *everything* I look at from the USA (ie: virtually all sites at 350-370k), which cannot be right.

I hope it is something as simple as RWIN values on the non Inktomi proxies, maybe that can be fixed fairly easily and bring them(Poplar and other slow ones) into line with the Inktomi Proxies.

In my own (admittedly non scientific) testing - the Proxies I get good speeds from are all Inktomi (according to Robins page - but someone told me that page was out of date).

cheers

Ian

mr-b · 02-04-2005, 21:40

Quote:

Originally Posted by IanUK

I can understand that if you are pulling in a cached file from one of the proxies, then you will get better speeds, but my own experience seems to suggest that the Poplar proxies are not caching *anything* from the USA (ie: virtually nothing goes above 150k) whereas the Colchester/Hersham/Swansea proxies cache *everything* I look at from the USA (ie: virtually all sites at 350-370k), which cannot be right.

Yes that does sound strange.
But the key here is that I was only testing one object from one point (although over several different network paths) and you can't really do a reliable diagnosis from that. So more data points are required. Plus TCP window size is just one of several things to check in a trace e.g. there could be packet retransmits etc.

You can check whether an object is cacheable (and cached) by examining the HTTP headers. It should be pretty obvious.
You can always use the cacheability checker http://www.ircache.net/cgi-bin/cacheability.py if you don't want to use wget.

Rik · 02-04-2005, 23:35

I use Luton proxies transparently and im downloading Service Pack 1 for Server 2003 from www.microsoft.com at 360KBS

No problems here

Chrysalis · 03-04-2005, 06:15

good posts mr-b, I have noticed the speed disprencancy on uk and eu sites tho, including my own server, I did several speed tests over http from a server that does 360kB over single threaded ftp and the results confirmed my problem. What you say about rwin makes sense as to why the issues might be occuring, I can post a http link later to a dedicated 100mbit link in germany and let you do some further analysis if you like.

I will also go back to a slow proxy and then run this url below on it and see what I get.

http://www.ircache.net/cgi-bin/cacheability.py

mr-b · 03-04-2005, 12:58

Quote:

Originally Posted by Rik

I use Luton proxies transparently and im downloading Service Pack 1 for Server 2003 from www.microsoft.com at 360KBS

No problems here

It could already be cached, or it may well be (OK, I'd be very surprised if it wasn't the case!) that MS use a form of global content delivery network where they have download servers all over the world and MS' download web sites will always redirect you to the closest fastest-responding server. Proxies are often used for this function as well as they are usually much faster and more resilient than web server farms.
You can tell which actual servers are being used by using 'netstat' which will list all of your connections. This method won't work of course if you are manually specifying a proxy.

I'll be happy to run tests using wget on any URLs that ppl list - although it really is quite simple and more meaningful to do the tests yourself.

Chrysalis · 03-04-2005, 17:53

here is link

http://www.hostingfreak.net/50MB

interestingly I am getting better results now.

no proxy specified few dips avg speed 330kB
nottingham 360kB no dips
colchester 360kB no dips

when I run that cacheability site it just seems to hang when I put in the url.