On 2/05/2014 10:01 a.m., Lawrence Pingree wrote: > 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. Configure the directory: cache_dir rock /path/to/cache 1000 then run squid -z to format the database. All the other settings are supposed to be optional now AFAIK. NP: Very large rock caches (more than a few tens of GB) can take a while to load on startup. > 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. Strange. There is nothing in SMP which should interfere with interception from what I know of how they all operate. Amos > -----Original Message----- > From: Amos Jeffries > > 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 > > >
