Re: Linux filesystem speed comparison

Steven Wilton wrote:
>>
>> It depends on the balance of hardware, but I'd be extremely
>> surprised if XFS performs better than either reiser or ext2/3 for
>> Squid workloads on /any/ system. So I have to assume your
>> methodology is slightly flawed. ;-)
>
>
> That's what I thought, but there has been a bit of XFS work in recent
> kernels, and after my initial observations I was wondering if this
> has improved the performance with squid's filesystem load.

It's been at least a year since I tried XFS, so I reserve the right to
be horribly wrong. But it was so far behind the other options when I
last toyed with it that I completely wrote it off as wholly
uninteresting for Squid workloads. ;-)

>> While I have found that ext3 (when configured correctly) has
>> improved performance for Squid quite a bit over ext2, it is still
>> no match for ReiserFS on our hardware, which always has more than
>> enough CPU for the disk bandwidth available. But, I can certainly
>> imagine a hardware configuration that would lead to ext3 performing
>> better than ReiserFS (especially since Duane has proven that it is
>> possible by putting 6 10,000 RPM disks on a relatively wimpy CPU
>> and testing the configuration extensively with polygraph).
>
>
> The machines are a bit old (P3-500), but they've only got 3x 9Gb SCSI
> cache disks, and they're not running anywhere near 100% load.

Heheh..."only" is a relative term. Our old 500 Mhz boxes couldn't even
work two 7200 RPM IDE disks (on different buses, of course) effectively,
and three provided a barely measurable boost. I'd be surprised if you
aren't able to easily max your CPU with ReiserFS on a polygraph run on
these boxes...and it will probably happen at around 110 reqs/sec.,
assuming reasonable configuration of kernel and Squid.

>> I'm always interested in conflicting reports, however. If you've
>> got a case that makes XFS faster for Squid against polygraph, I'd
>> love to see the results and configuration.
>
>
> I had a quick look at polygraph before, but I didn't get very far in
> testing it. I would like to produce some polygraph figures for the
> proxies, so I will see what I can do to make a test system. My only
> concern is that the proxies may be able to process requests faster
> than the polygraph hardware can serve them.
>
> From memory there are a lot of options available for polygraph, and
> I was
> not sure how to produce meaningful results. Any help would be
> appreciated.

I've got no magic formula for making Polygraph go. I can say that it
built easily on Linux and FreeBSD last time I tried on either platform,
and the documentation that Alex wrote for preparing for the cacheoffs
was very helpful in getting an environment that works for roughly
replicating publicly available proxy performance numbers, including
those that Duane, myself, and others have published for Squid.

Oh, and as for your concern that the Polygraph boxes might not be able
to work your Squid hard enough to stress it...don't worry. Polygraph
has a lot less work to do than Squid, and Alex has done a nice job
making it go plenty fast. No single Squid instance will be a match for
even a single polygraph box of equal hardware. I've been able to use a
laptop for /both/ sides of the polypair and successfully stress Squid on
similar hardware to what you're testing (not recommended, since results
from a single box polypair wouldn't be trustworthy or sanely comparable
to a real pair of poly boxes--but in a pinch it will do).

Just some thoughts. Performance has become progressively less important
over the years as hardware has become so much faster. I only see a few
cases a year where we even need more than one Squid box, for anything
other than redundancy (though sometimes the one Squid box is obscenely
powerful). So, my Squid performance testing has become an occasional
hobby rather than a core interest...so new results for various
configurations might surprise me just as much as anyone else.
Received on Mon Apr 11 2005 - 19:41:26 MDT