Date: Thu, 27 Dec 2007 00:32:29 +0900 From: "Adrian Chadd" <adrian@freebsd.org> To: "Brett Glass" <brett@lariat.net> Cc: stable@freebsd.org Subject: Re: SMP on FreeBSD 6.x and 7.0: Worth doing? Message-ID: <d763ac660712260732r9a9b86cud13417108e4657e7@mail.gmail.com> In-Reply-To: <200712261512.IAA27697@lariat.net> References: <200712220531.WAA09277@lariat.net> <476FBED0.2080400@samsco.org> <200712241549.IAA19650@lariat.net> <476FDA10.4060107@samsco.org> <200712241653.JAA20845@lariat.net> <476FE868.8080704@samsco.org> <200712241756.KAA21950@lariat.net> <d763ac660712241820s38237d99x1243862095780dc6@mail.gmail.com> <4772529D.9010805@samsco.org> <200712261512.IAA27697@lariat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/12/2007, Brett Glass <brett@lariat.net> wrote: > Scott, Adrian: > > Even more interesting would be a storage schema for caches that rests > on top of FreeBSD's GEOM facility. One could bypass all filesystems > but still take advantage of the driver architecture. The biggest bonuses to gain high throughput with web caches, at least with small objects, is to apply temporal locality to them and do IO in $LARGE chunks. You then want to pull tricks with your memory cache so you throw away RAM in cluster-sized chunks - the objects grouped by temporal locality above - because really, if you throw away a 4k page, your costs of performing disk IO to read that 4k versus reading say, 32k or 64k, are pretty freaking similar (the same if you happen to be on the same track, slightly more if you're straddling tracks.) So you also want to pull those tricks. If you have two small objects (<64k) which are 50% likely to be fetched together, then by grouping them into one IO operation you're effectively slicing the seeks needed in half with very little impact. Well, there's an impact - you suddenly start pulling lots more data off disk. Could -that- be done without too much trouble? I've looked at madvise() to pull these tricks with mmap()'ed backing files but, again, I've not hit the point where I'm looking to optimise Squid's disk storage. There's just too much catching up to do to varnish's memory-only workload performance. Damn you phk. :) -- Adrian Chadd - adrian@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d763ac660712260732r9a9b86cud13417108e4657e7>