Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Just a quick bit of background.... our winxp lab of 16 computers is using 2-way satellite via a debian linux proxy server using Squid. The proxy server was preconfigured by the 2-way sat people so i know the default setup is ok. We have been using the setup for over a year now. However, the surfing speed is painful at best, and i am looking for ways to speed things up.
I am a complete newbie to linux, so please try to be nice, hehe.
What i have been able to piece together from looking at the squid.conf file is that the cache file is on a separate partition using 500mb of space. Would increasing this size be beneficial?
(cache_dir ufs /space/cache 500 16 256)
Now, currently the problem is that a very small amount of caching seems to be taking place. Isn’t the idea of a server cache to be that once 1 workstation loads a page, it gets cached and subsequent workstations would instead retrieve the webpage files from the cache (instantly)?
Does squid clear its cache at certain times by default?
One last question.... i recently got help in setting up a brand new ibm eserver which is currently running debian linux. Seeing as how the proxy server is also configured for debian linux, would i be able to move squid over to the new server instead of having a standalone squid proxy server?
looks like since you aren't specifying a maximum memory object size you are using the default (i think it's 8 KB) which is very small... try specifying a bigger size, this way more objects will get loaded into your (fast) RAM instead of your (slow) hard disk... try 128 KB for example:
Code:
maximum_object_size_in_memory 128 KB
you might also wanna give the heap lfuda replacement policy a shot:
Code:
memory_replacement_policy heap LFUDA
rememeber to do a "squid -k reconfigure" after making changes to squid.conf...
Thanks, yes my maximum_object_size_in_memory was set at default 8KB so i'll make that change. A couple of questions regarding that:
Does that mean that all objects larger than 8kb were not being cached at all, or just not in RAM?
Does this also mean that if i added more RAM then even more objects could be loaded directly into RAM instead of the HD?
Also, how long do contents stay cached in the proxy server before being dumped? Is there any way i can have contents hang around a lot longer (ie days or weeks)?
I'll try both of these changes to see what happens.
Originally posted by bluesky2005 Does that mean that all objects larger than 8kb were not being cached at all, or just not in RAM?
yeah, it means only objects smaller than 8KB were cached in your ram... anything above 8kb would go to the disk...
Quote:
Does this also mean that if i added more RAM then even more objects could be loaded directly into RAM instead of the HD?
yeah, just make the necessary size adjustment to the "cache_mem" option... i have some squid boxes with 512MB of ram on them and i usually set a cache_mem of about 256MB give or take, depending on what other stuff i have running on the boxes... your milage will vary... so actually if you already have more free ram you could adjust the cache_mem size and make it bigger without adding more ram physically... of course you need to leave a good amount of headroom when doing this, cuz if you use a cache_mem size that's too big then the objects will go into your swap and it would defeat the purpose of having them in ram in the first place... so consider any other progs you are running and stuff, and remember also that squid doesn't just use memory for the cache, it also uses memory for its own internal use... i'd recommend that if, for example, your box has 128MB of ram, you should leave the cache_mem at 64MB... 64 megs might not sound like a lot, but for a setup of only 16 clients it's actually quite decent...
of course i have no idea how much ram you have or what other programs you are using so i can't really make any specific suggestions - i'm just trying to give you an idea of what to consider...
AFAIK, on a stand-alone squid box, the swap should never even get touched at all...
Quote:
Also, how long do contents stay cached in the proxy server before being dumped? Is there any way i can have contents hang around a lot longer (ie days or weeks)?
to answer this question google a bit about squid's cache replacement policies...
there's also some very quick documentation in the /etc/squid/squid.conf.default file, for example:
Quote:
# TAG: cache_replacement_policy
# The cache replacement policy parameter determines which
# objects are evicted (replaced) when disk space is needed.
#
# lru : Squid's original list based LRU policy
# heap GDSF : Greedy-Dual Size Frequency
# heap LFUDA: Least Frequently Used with Dynamic Aging
# heap LRU : LRU policy implemented using a heap
#
# Applies to any cache_dir lines listed below this.
#
# The LRU policies keeps recently referenced objects.
#
# The heap GDSF policy optimizes object hit rate by keeping smaller
# popular objects in cache so it has a better chance of getting a
# hit. It achieves a lower byte hit rate than LFUDA though since
# it evicts larger (possibly popular) objects.
#
# The heap LFUDA policy keeps popular objects in cache regardless of
# their size and thus optimizes byte hit rate at the expense of
# hit rate since one large, popular object will prevent many
# smaller, slightly less popular objects from being cached.
#
# Both policies utilize a dynamic aging mechanism that prevents
# cache pollution that can otherwise occur with frequency-based
# replacement policies.
#
# NOTE: if using the LFUDA replacement policy you should increase
# the value of maximum_object_size above its default of 4096 KB to
# to maximize the potential byte hit rate improvement of LFUDA.
#
# For more information about the GDSF and LFUDA cache replacement
# policies see http://www.hpl.hp.com/techreports/1999/HPL-1999-69.html
# and http://fog.hpl.external.hp.com/techr...L-98-173.html.
#
#Default:
# cache_replacement_policy lru
# TAG: memory_replacement_policy
# The memory replacement policy parameter determines which
# objects are purged from memory when memory space is needed.
#
# See cache_replacement_policy for details.
#
#Default:
# memory_replacement_policy lru
BTW, you should also tweak the maximum object size for your disk cache, as well as the policy... the default is 4MB...
since you currently have a 500-meg disk cache i'd suggest upping the disk object limit to 8 or maybe 12 megs... for example:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.