Back to Proxy Cache main section
A rock cache stores all cached objects in a single database file, cut into fixed-size slots. Unlike the classic disk caches (aufs, ufs, diskd), a rock cache can be shared by all the proxy workers: it is the cache type made for proxies that use several CPUs.
¶ Why rock when the proxy uses several CPUs
To use several CPUs, the proxy runs several workers, independent processes that share the traffic. Each worker has its own view of the disk caches:
- An aufs, ufs or diskd cache cannot be shared: it belongs to one worker. An object stored by worker 1 is not seen by worker 2, which downloads and stores it again in its own cache. Several workers therefore keep duplicate copies and each one reaches a lower hit ratio.
- A rock cache is shared: an object stored by any worker is served to all the others. This gives the best hit ratio and the best use of the disk on a multi-CPU proxy.
Disk I/O for rock caches is done by separate helper processes (diskers). They can become a bottleneck under heavy load, so give the proxy a large enough memory cache: it is shared by all workers too, and serves the most popular objects without reading the disk. The default configuration only keeps small objects in the memory cache; raise its size and its maximum object size on busy proxies.
¶ How Artica places your caches
| Cache | One worker | Several workers (multiple CPUs) |
|---|---|---|
| Central Cache (rock, see below) | not used: it needs several workers | shared by all workers |
| Caches Center cache of type rock | used | shared by all workers |
| Caches Center cache of type aufs / ufs / diskd | used | used by one worker only: the process chosen in the cache settings (process 1 by default) |
- In multi-CPU mode, the New cache Folder button of the Caches Center creates a rock cache automatically.
- An aufs cache assigned to a process that does not exist (for example process 4 when the proxy runs 2 workers) is not used; the cache status page shows it as not supported (see Unsupported storage type using multiple CPUs). Edit the cache and choose an existing process, or create a rock cache instead.
- To spread several aufs caches over the workers, give each worker its own cache (one folder per process), ideally on separate disks.
¶ Enable the Central Cache
- On the left menu, choose “
Caching” > “Central Cache”. - The page shows the number of workers, the cache size and how full it is. It also computes the maximum size you can use (see Size and memory below).
- Click on the “Inactive” link.
- Turn on the “Enable the Feature” option.
- Set the directory where the cache is stored. The rock database is created in a
rocksub-directory of this folder. Prefer a dedicated disk or partition. - Choose the global size of the cache in the drop-down list.
- In Maximum object size (KB), set the largest object the cache may store (128 KB by default). Larger objects are not stored in this cache: raise the value if you want to cache downloads such as updates or installers.
When you apply the settings, Artica rebuilds the cache configuration, creates the rock database and then:
- restarts the proxy when the rock cache is new or its directory or size changed (the proxy cannot add or resize a rock cache while it runs);
- only reloads it when nothing changed in the rock cache itself.
Disabling the feature removes the cache from the proxy and deletes the rock directory, only when it really contains a proxy cache.
¶ Size and memory
The proxy keeps the index of a rock cache in shared memory (/dev/shm). The largest size Artica proposes is therefore computed from the shared memory available: about 32 times 70% of /dev/shm. If the size you need is not proposed, add memory to the server.
¶ Advanced options
SWAP timeout:
The proxy will not start writing a cached object to, or reading a cached object from, the disk if it estimates that the operation will take more than the specified number of milliseconds. By default, and when set to zero, the disk I/O time limit is disabled. Ignored with a blocking I/O module, because blocking synchronous I/O does not let the proxy estimate the expected wait time.
Max SWAP rate:
Artificially limits disk access to the specified I/O rate. Write requests that would push the average I/O rate above the limit are delayed. Individual read requests (cache HITs) are not delayed, but they count in the measured rate and wait in the same queue as writes, so they may wait longer when this value is small. This is useful on file systems that buffer "too many" writes and then block the proxy and other processes while committing them to disk. Usually used together with the SWAP timeout to avoid long delays and queue overflows when disk demand exceeds the disk bandwidth. By default, and when set to zero, the I/O rate limit is disabled.
The slot size of the rock database is fixed by Artica to 32,000 bytes.
¶ Check that the cache works
- Caching > Status shows each cache the proxy uses, with its size and how full it is. The Central Cache page shows the same figures for the rock cache.
- In
/etc/squid3/caches.conf, theworkersline gives the number of workers. Rock caches appear once ascache_dir rock …lines; aufs caches appear inside theif ${process_number} = Nblock of their worker. - A rock cache that never fills: check that objects are smaller than the maximum object size, and that the traffic is cacheable (HTTPS content is only cached when SSL inspection is enabled for the website).