From: Neil Murray An idea that occurred for developing squid is to add a disk2client program. When a client requests an object greater than a settable trigger size, squid passes the client connection to disk2client with the path to the requested object and disk2client takes on the responsibility to feed the object down to the client. I envisage disk2client working similarly to squid with 1 disk2client program handling all passed across connections using a select-event loop. - Advantages, the memory size of squid should be reduced as the objects read into disk2client process memory, will not impact squid's process memory usage. The cache_mem parameter would become associated with disk2client. Disk2client should be a simpler program as it only deals with disk files and client connections (and some communications to squid itself). Increases the effective number of file descriptors available since once squid hands across a client connection squid can then make that file descriptor available for a new connection. This is a side benefit. Multi-cpu systems could run the disk2client separate to squid. - Disadvantages, more system memory used as there is another process with duplicated code for some things. Changes in squid would need to be echoed across to disk2client but that could handled by sharing code files for the common pieces. The overhead of transferring the file descriptors and path info across to disk2client. One extension to consider about disk2client is to make handle all read file from disk and pass to client requests regardless of size. This means that squid can lose the disk cache reading code altogether. Unfortunately this would mean disk2client would have to be able to pass a client connection back to squid if the disk object wasn't there so squid could connect to the original site again and fetch the object down.