Re: [squid-users] feature requests

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Fri, 09 May 2014 00:04:46 +1200

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
>
>
>
Received on Thu May 08 2014 - 12:05:03 MDT

This archive was generated by hypermail 2.2.0 : Thu May 08 2014 - 12:00:04 MDT