On Sat, Aug 11, 2007, Michel Santos wrote:
> > * don't write everything cachable to disk! only write stuff that has
> > a good chance of being read again;
>
> there is a "good chance" beeing hit by a car when sleeping in the middle
> of a highway as well there is a chance not beeing hit at all :)
:)
> well that was my knowledge about chances but here are not so many options,
> or you are a hell of forseer or you create an algorithm, kind of inverting
> the usage of the actual or other cache policies applying them before
> caching the objects instead of controlling the replacement and aging
No, you run two seperate LRUs, glued to each other. One LRU is for new
objects that are coming in, another LRU is for objects which have been
accessed more than once.
The interesting trace to do on a production cache (remember, I don't have
access to production ISP caches and haven't for quite a while) is to calculate
the chance of seeing a subsequent request HIT after a certain period of time.
You want to know what % of your objects that are being requested are never
going to be seen again, where "never" can be some time length (say, a day;
you can vary it in your experiment.)
The idea here is that a large % of your requests are once off and won't
be seen again; what you want to do is keep those in memory in case they're
seen again and not write them to disk. You only want to write stuff to
disk that has a higher chance of being requested later.
It also may make your memory cache more efficient as you're not so worried
about pushing hot objects out of the way to make room for transient bursts
of new, never seen again objects. As an example, ZFS does this for its
memory cache management to prevent a "find /" type workload killing the
hot page cache set.
So you're not predicting the future. :) This is all mostly conjecture on
my part, but the papers from the early 2000's list these techniques as
giving noticable returns.
> interesting project because caching is not so hot anymore, bandwidth is
> cheap in comparism to 10 years ago and the heck today is PtP so I mean,
> probably hard to find a sponsor with good money. The most wanted feature
> is proxying and acl but not cache so I guess even if there are ever geeks
> like us which simply like the challenge to get a bit more out of it most
> people do not know what this is about and do not feel nor see the
> difference between ufs and coss or whatever. To be realistic I understand
> that nobody cares about diskd as nobody cares really about coss because it
> would be only for you or for me and some more and so Henrik works on aufs
> because he likes it but at the end it is also only for him and some
> others. And this sum of some do not have money to spend it into
> coss/aufs/diskd. And probably it is not worth it when the principal users
> have a 8Mb/s adsl for 40 bucks why they should spend money on squid's fs
> development?
A few reasons:
* I want to do P2P caching; who wants to pony up the money for open source
P2P caching, and why haven't any of the universities done it yet?
* bandwidth is still not free - if Squid can save you 30% of your HTTP
traffic and your HTTP traffic is (say) 50% of 100mbit, thats 30% of
30mbit, so 10mbit? That 10mbit might cost you $500 a month in America,
sure, but over a year? Commodity hardware -can- and -will- effectively
cache 100mbit for under a couple thousand dollars with the right
software, and if done right the administration will be low to none
existant. You'd pay for the cache inside 6 months without having to try;
if the lifespan is longer than 12 months then its free money.
* Now take the above to where its $300 a megabit (Australia), or even more
in developing nations..
* .. or, how about in offices who want to provide access control and filtering
of their 10-100mbit internet link ..
* .. etc.
There's plenty of examples where web caching is still important - and I'm
just touching the forward caching; lets not even talk about how important
reverse caching is in content delivery these days! - and there's still a
lot of room for Squid to grow. Doubling the request rate and tripling the
disk throughput for small objects is entirely within reason, even on just
one CPU. Don't get me started on the possibilities of media/P2P caching
on something large like a Sun thumper, with 20-plus SATA disks in a box.
Would you like Squid to handle 100mbit+ of HTTP traffic on a desktop PC
with a couple SATA disks? Would you like Squid to handle 500-800mbit of
HTTP traffic on a ~$5k server with some SAS disks? This stuff is possible
on today's hardware. We know how to do it; its just a question of
writing the right software.
Adrian
Received on Sun Aug 12 2007 - 16:32:48 MDT
This archive was generated by hypermail pre-2.1.9 : Sat Sep 01 2007 - 12:00:03 MDT