John Reiser wrote:
Les Mikesell wrote:
Reasonable proxy behavior would mostly fix that.
A base + software development install for x86 is about 3GB on disk,
or 1.5GB on install media. Many proxies don't cache that much,
so the savings usually are not so large.
To get an idea of how this relates to the _default_ Squid settings :
#Default:
# cache_dir ufs /var/spool/squid 100 16 256
That 100 in the above config line means 100 MB of storage maximum.
The "ufs" in that config line means if squid is blocked on disk I/O
it will not attempt to cache any other requests until unblocked.
There are other options, but that is the default. If you have your
squid cache on an ext3 partition ( the default ) there is quite a bit
of blocking for the kjournald. Using ext2 performs much better.
#Default:
# maximum_object_size 4096 KB
I think that line is obvious, it means a lot of RPMs won't be cached
at all.
I won't get into the specific settings for determining what gets
purged from the cache as new requests roll in. Basically, the default
settings are more likely to purge large files ( most RPMs ) in order
to allow many small files to remain cached.
So the _default_ squid settings are almost worthless for caching RPMs
either for updates or installs. That is not to say that squid could
not have a configuration optimized for caching RPMs. However, for
many people it is much easier to install InstantMirror or something
like it than learn the ins and outs of squid configuration and tweak
those settings. You will get better performance easier with an actual
local mirror.
Admins in larger organizations are more likely to spend the effort to
set up a mirror on their local network, or even twiddle with cache
settings if that is the solution best for them. Anything that can be
done to encourage less experienced or less clueful admins to set up
local mirrors is a Good Thing. At the very least it improves the
update / install experience and reduces stress on internet mirrors. I
can't think of any negatives to local mirrors off the top of my head.
Charles Dostale
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
