🚀 go-pugleaf

With all due respect, that's oversimplified and based on assumptions
that aren't necessarily valid, depending on the particular proxy and its
configuration.  I've never seen a case where a properly configured
Cacheflow of appropriate size was slower than a non-cached connection. 

You seem to forget that the typical proxy has a very fat upstream pipe
(comparable to the very fat downstream pipe), as compared to the typical
ADSL or cable user.  Another important point is that putting the load on
the proxy instead of the transit pipe tends to improve throughput for
all subscribers; i.e., not using the proxy can be selfish and
counterproductive.

p.s.  As a real world data point, I'm testing a Cacheflow box at
Sonic.net, and the results are very impressive even though Sonic's
non-proxied speeds are excellent.


In <3A870DC7.E8678FFE@mynetwatchman.com>, Lawrence Baldwin
<baldwinlSPAMMENOT@mynetwatchman.com> wrote:

>Spark wrote:
>> 
>> Is there any advantage or disavantage to using the proxy server settings? I
>> am not using them now but I am curious.  Below is the AT&T RR quote on the
>> subject:
>> 
>> Thanks,
>> spark
>> 
>> "Our proxy servers enhance the performance of your high-speed connection.
>> The proxy server caches - or stores - the most frequently visited sites and
>> delivers them upon request. By caching such sites, your request doesn't go
>> through the sometimes congested Internet, so you experience a faster
>> download. The proxy servers automatically know when content changes, so you
>> are always get the most up-to-date pages. This cache is built as AT&T
>> Broadband subscribers visit popular sites on the web.
>> Although you are not required to use the proxy servers, enabling them will
>> result in the best experience. "
>
>
>Whether using a cache server will improve your performance vs. NOT using
>it is dependent on a *lot* of variables.  Realize that there is still a
>*cost* of using a cache server:
>
>* If it is handling a lot of users, the cache server can return pages
>slower than the target server itself. 
>
>* Cache server is likely caching a lot of the content on *disk*...the
>actual web server is likely caching most of the popular pages in
>RAM...and thus can deliver pages faster
>
>* Using a cache server still requires *some* communication to the actual
>web server.  After you request a page from the cache server, it issues
>an HTTP GET to the real server but includes the "if-modified-since
>mm/dd/yyy" directive.  It still has to wait for a response, and then may
>even have to get the page if it has changed since being cached.
>
>I have actually taken some time to capture some packet traces using and
>NOT using a cache server when accessing some popular sites (e.g.
>yahoo.com, cnn.com, etc...).
>
>These generalization certainly do NOT apply to all situations, but this
>is what I noticed:
>
>* When using a cache server it always took longer for me to START
>receving my pages (sometimes 300-1000ms longer).  (presumably this is
>the delay to check for page modifications and retrieve the cached data
>from disk).  However, once the data started flowing, I would get the
>rest of the page at a much faster RATE than talking to the remote
>server.
>
>This makes since, because in my case, the cache server was just 1 router
>hop away with nearly 45Mbps relatively uncongested bandwidth between me
>and it.
>
>
>Though getting pages directly from the server was actually FASTER is
>many cases...it would start sending data almost immediately, though at a
>slighly slower pace.  Sometimes the overhead of the cache server is
>actually MORE than the delay and congestion incurred to talk to the
>remote server---sometimes its less.
>
>Here are cases where cache servers will likely improve your experience:
>
>* You frequently access popular content
>* Cache server "close" to you and high-powered
>* Providers backbone connections are congested
>* Real servers are slow
>
>Here are cases where cache servers will likely degrade your experience:
>
>* Accessing obscure or highly dynamic content
>* Cache server is "far" away and/or underpowered
>* Providers backbone is NOT congested
>* Real servers are very fast (e.g. large web farm with local
>load-balancing/caching)
>
>lb.

-- 
Best regards,
John Navas     <http://navasgrp.home.att.net/>
     CABLE MODEM/DSL GUIDE:  <http://Cable-DSL.home.att.net/>