On Thu, 2006-09-07 at 12:47 -0500, Les Mikesell wrote: > On Thu, 2006-09-07 at 18:08 +0100, Lance Davis wrote: > > > CentOS 3 wont have the same issue because all updates are referenced via a > > round robin set of mirror.centos.org, which will always be seen as the > > same url by the proxy. > > What's the problem with that scheme? It's hundreds of times faster > on my second and subsequent machines - and would be for anyone else > going through a proxy configured to cache large objects. What is wrong with that scheme is that only 1 mirror is listed ... if you loose the connection, if it gets overloaded in the middle of your transfer, etc. then there is no failover. > > > > > > > Maybe those claimed 1.5 million users are really a few users or > > > locations > > > with a lot of machines... Letting proxies work as designed would > > > make sense to me. > > > > Well the issue is that you want a proxy to always hit the same mirror - > > (which you can configure) whereas we want to spread the load between the > > mirrors ... > > What I want is for the default install to work using standard > cache techniques. The 'you can configure' concept only works if > you know everyone else sharing the same proxy and can pre-arrange > every file download with all of them which is pretty unlikely in > any organization large enough to even have a proxy. A scheme that > uses the same URL for the same file will always work automatically. > If you do this, spreading the load won't be an issue since there > will actually only be one download. If you can't use the same > set of mirrors as centos3, there has to be some way to make this > happen based on some computation that would be repeatable - perhaps > a server-side check that can see the requester's public source > address and give back the best mirror URL or a sorted list that > would always be the same for that source IP. If you have alot of machines doing the same updates from the same place (and so are behind a proxy server) then hosting the updates yourself on a local mirror would be much easier and you would not have to worry about any of these issues. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: <http://lists.centos.org/pipermail/centos/attachments/20060907/3d794dae/attachment-0005.sig>