The Cache Options page provides access to some important parts of the Squid configuration file. This is where the cache directories are configured as well as several timeouts and object size options.
The Cache directories option sets the cache directories and the amount of space Squid is allowed to use on the device. The first example displays an example cache_dir line in the squid.conf file, while the figure below shows the Cache Options screen in Webmin where the same options can be configured.
cache_dir ufs /cache0 1500 8 256
The directive is cache_dir while the options are the type of filesystem, the path to the cache directory, the size allotted to Squid, the number of top level directories, and finally the number of second level directories. In the example, I've chosen the filesystem type ufs, which is a name for all standard Unix filesystems. This type includes the standard Linux ext2 filesystem as well. Other possibilities for this option include aufs and diskd.
The filesystem type is a new feature of Squid 2.3 and above. Versions below 2.3 do not need this option, and will not accept any option in its place. 2.2 only supports UFS and Async UFS filesystems, which are chosen at compile time. The GUI example in the figure is for Squid version 2.2.STABLE5. Newer versions will contain additional fields.
The next field is simply the space, in megabytes, of the disk that you want to allow Squid to use. Finally, the directory fields define the upper and lower level directories for Squid to use. Calculating the L1 number precisely is tricky, but not difficult if you use this formula:
x=Size of cache dir in KB (i.e. 6GB=~6,000,000KB) y=Average object size (just use 13KB) z=Number of directories per first level directory (((x / y) / 256) / 256) * 2 = # of directories As an example, if my cache used 6GB of each of two 13GB drives: 6,000,000 / 13 = 461538.5 / 256 = 1802.9 / 256 = 7 * 2 = 14 So my cache_dir line would look like this: cache_dir ufs 6000 14 256
The rest of the Cache Options page is a bit of a hodge podge of mostly simpler options. Generally most configuration will take place on this page, as it addresses many of the tunable items in Squid that can make a difference in performance.
Average object size is the average size of objects expected in your cache. This item is generally safe at its default value of 13KB. In older versions of Squid (prior to 2.3) this option effected the number of filemap bits set aside by Squid at runtime. In newer Squids filemap bits are configured dynamically, as needed, and so configuration of this option is unnecessary and arguably pointless. This option will go away in some future version of Squid. Until then, it correlates to the store_avg_object_size directive.
Objects per bucket is the number of objects in each store hash table. Again, not worth bothering to change it, as its default value is probably a good safe value, and changing it provides little or nothing in the way of performance of efficiency improvements. Corresponds to the store_objects_per_bucket
Don't cache URLs for ACLs allows you to easily pick which ACL matches will not be cached. Requests that match the selected ACLs will always be answered from the origin server. This option correlates to the always_direct directive.
Maximum cache time defines the maximum time an object will be allowed to remain in the cache. This time limit is rarely reached, because objects have so many occasions to be purged via the normal replacement of the cache object store. However, if object freshness is of prime importance, then it may be worthwhile to lower this from its default of 1 year to something much shorter, such as 1 week, though it is probably counter-productive to do so for most users. This option configures the reference_age parameter.
Maximum request size is the maximum size of request that will be accepted by Squid from the client. The default is 100 KB, however, in environments where the POST method is used to send files to web servers, it will probably be necessary to raise this limit to something more reasonable. 4-8 MB is probably a good size that will permit most uploads without any problems. Note that this bears no relation to the size of object that is being retrieved, it only effects the size of the HTTP request being sent from the client. This option corresponds to the request_size directive.
Failed request cache time is the amount of time that a request error condition is cached. For example, some types of connection refused and 404 Not Found errors are negatively cached.
DNS lookup cache time is the length of time that DNS lookups are cached. Squid provides functionality as a basic caching nameserver, in order to further accelerate web service through the proxy. This value defaults to 6 hours and correlates to the positive_dns_ttl directive. If rapid updates of cache DNS data is required, such as to keep up with dynamic DNS systems or to avoid load balance problems with local network sites in a website acceleration environment, it may be wise to reduce this value significantly. Insuring you have reliable and suitably fast DNS service on the local network is mandatory, however, if you do reduce this value by a large amount.
Failed DNS cache time is the time period for which failed DNS requests are cached. This option corresponds to the negative_dns_ttl directive, and defaults to 5 minutes. This option rarely needs tuning.
Connect timeout is simply an option to force Squid to timeout connect requests. Some systems (notably older Linux versions) can not be relied upon to time out connect requests. For this reason, this option specifies the timeout for how long Squid should wait for the connection to complete. This value defaults to 120 seconds (2 minutes) and correlates to the connect_timeout directive.
Read timeout is the timeout for server-side connections. Each successful read() request the timeout is reset to this amount. If no data is read within this period of time, the request is aborted and logged with ERR_READ_TIMEOUT. This option corresponds to read_timeout and defaults to 15 minutes.
Site selection timeout is the timeout for URN to multiple URLs selection. URN is a protocol designed for location-independent name resolution, specified in RFC 2169. This option configures the siteselect_timeout directive and defaults to 4 seconds. There is probably no need to change this.
Client request timeout is the timeout for HTTP requests from clients. By default the value is 5 minutes, and correlates to the request_timeout directive.
Max client connect time is the time limit Squid sets for a client to remain connected to the cache process. This is merely a safeguard against clients that disappear without properly shutting down. It is designed to prevent a large number of sockets from being tied up in a CLOSE_WAIT state. The default for this option is 1440 minutes, or 1 day. This correlates to the client_lifetime.
Max shutdown time is the time Squid allows for existing connections to continue after it has received a shutdown signal. It will stop accepting new connections immediately, but connections already in progress will continue to be served for this amount of time. This option corresponds to the shutdown_lifetime configuration directive and defaults to 30 seconds, which is a good safe value. If rapid down->up time is more important than being polite to current clients, it can be lowered.
Half-closed clients defines Squids behavior towards some types of clients that close the sending side of a connection while leaving the receiving side open. Turning this option off will cause Squid to immediately close connections when a read(2) returns "no more data to read". It's usually safe to leave this at the default value of yes. It corresponds to the half_close_clients directive.
Persistent timeout is the timeout value for persistent connections. Squid will close persistent connections if they are idle for this amount of time. Persistent connections will be disable entirely if this option is set to a value less than 10 seconds. The default is 120 seconds, and likely doesn't need to be changed. This option configures the pconn_timeout directive.
WAIS relay host and WAIS relay port are the WAIS host and port to relay WAIS requests to. WAIS, or Wide Area Information System, is a system to catalog and search large amounts of data via a WAIS or WWW browser. WAIS is a mostly deprecated protocol, but some sites probably do still exist, though this author has been unable to locate any to satiate his curiosity about the subject. These options correspond to the wais_relay_host and wais_relay_port directives, and defaults to localhost and 8000.