Hi Amos, Thanks for your help in understanding my request. I have attempted to create a rock store but was unsuccessful. There doesn't seem to be very good guidance on the proper step by step process of creating a rock store. I came across crashes the last time i attempted it. Also, I am using an x86 platform (32 bit) with multiple cores, when I attempted to use SMP mode with multiple workers, instantly my intercept mode stopped functioning. I couldn't figure out what was wrong so I'd love to get better guidance on this as well. Best regards, The Geek Guy Lawrence Pingree http://www.lawrencepingree.com/resume/ Author of "The Manager's Guide to Becoming Great" http://www.Management-Book.com -----Original Message----- From: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] Sent: Tuesday, April 29, 2014 1:20 AM To: squid-users@xxxxxxxxxxxxxxx Subject: Re: feature requests On 29/04/2014 4:17 p.m., Lawrence Pingree wrote: > > I would like to request two features that could potentially help with > performance. > See item #1 "Wait" ... <http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feat ure.2C_enhance.2C_of_fix_something.3F> Some comments to think about before you make the formal feature request bug. Don't let these hold you back, but they are the bigger details that will need to be overcome for these features to be accepted and useful. I will also suggest you test out the 3.HEAD Squid code to see what we have done recently with collapsed_forwarding, SMP support and large rock caches. Perhapse the startup issues that make you want these are now resolved. > 1. I would like to specify a max age for memory-stored hot objects > different than those specified in the generic cache refresh patterns. refresh_patterns are not generic. They are as targeted as the regex pattern you write. The only difference between memory, disk or network sources for a cache is access latency. Objects are "promoted" from disk to memory when used, and pushed from memory to disk when more memory space is needed. I suspect this feature will result in disk objects maximum age stabilizing at the same value as the memory cache is set to. - a memory age limit higher than disk objects needing to push to disk will get erased as they are too old. - a memory age limit lower than disk objects promoted from disk will get erased or revalidated to be within the memory limit (erasing the obsoleted disk copy). So either way anything not meeting the memory limit is erased. Disk will only be used for the objects younger than the memory limit which need to overspill into the slower storage area where they can age a bit beofre next use ... which is effectively how it works today. Additionally, there is the fact that objects *are* cached past their max-age values. All that happens in HTTP/1.1 when an old object is requested is a revalidation check over the network (used to be a re-fetch in HTTP/1.0). The revalidation MAY supply a whole new object, or just a few new headers. - a memory age limit higher than disk causes the disk (already slow) to have additional network lag for revalidation which is not applied to the in memory objects. - a memory age limit lower than disk places the extra network lag on memory objects. ... what benefit is gained from adding latency to one of the storage areas which is not applicable to the same object when it is stored to the other area? The overarching limit on all this is the *size* of the storage areas, not the object age. If you are in the habit of setting very large max-age value on refresh_pattern to increase caching take a look at your storage LRU/LFU age statistics sometime. You might be in for a bit of a surprise. > > 2. I would like to pre-load hot disk objects during startup so that > squid is automatically re-launched with the memory cache populated. > I'd limit this to the maximum memory cache size amount. > This one is not so helpful as it seems when done by a cache. Loading on demand solves several performance problems which pre-loading encounter in full. 1) Loading the objects takes time. Resulting in a slower time until first request. Loading on-demand we can guarantee that the first client starts receiving its response as fast as possible. There is no waiting for GB of other objects to fully load first, or even the end of the current object to complete loading. 2) Loading based on previous experience is as best an educated guess. That can still load the wrong things, wasting the time spent. Loading on-demand guarantees that only the currently hot objects are loaded. Regardless of what was hot a few seconds, minutes or days ago when the proxy shutdown. Freeing up CPU cycles and disk waiting time for servicing more relevant requests. 3) A large portion of traffic in HTTP/1.1 needs to be validated over the network using the new clients request header details before use. This comes back to (1). As soon as the headers are loaded the network revalidation can begin and happen while other traffic is loaded from disk. In loaded but cold cache objects the revalidation still has to be done and delays the clients further. The individual tasks of loading, revalidating, and delivering will take the same amout of CPU cycles/time regardless of when you do them. The nice thing about hot objects is that they are requested more frequently than other objects. So the probability of the very popular object being the first one demanded is extremely high. Getting it into memory and available for delivery without delay allows service for a larger portion of the traffic than any other loaded object would. [ keep in mind this next bit is just the maths and general traffic shapes, the actual graph scales and values will depend on your particular clients ] You can see the interaction of hot objects and on-demand loading in the traffic speed and client requests graph spikes on startup. With on-demand they are both exponential curves starting from some initial value [traffic speed low, requests peaking] and returning quickly to your normal operating values. The total length/width of that curve is the time taken to fill the memory cache with the currenly hot objects. Pre-loading the entire cache makes them start with a linear curve growing further *away* from normal to a maxima/minima value at the end of loading action, followed by a similar exponential curve back to normal over the time taked to revalidate the hot objects. The exponential return curve for pre-loading is similar and possibly shorter than the return curve for on-demand, but the total startup time spent above normal values is very often longer due to the linear growth on pre-loading [reasons being problems (1) and (2) above]. FYI: The main Squid developers have concentrated efforts in other areas such as; perfecting the COSS caching model into the one now called "rock" to load multiple objects in single fast disk loads[a], shared memory model with multiple processes dedicated to the tasks in parallel, removing the disk access in transactions that dont need them, and improved HTTP protocol handling. Interest, sponsorship, patches for these projects is very welcome. [a] ironically the biggest unresolved issue with rock today is that it holds up startup doing a pre-loading scan of its database slots very similar to your feature #2. HTH Amos
