Re: squid-1.2-SQUIDFS

--MimeMultipartBoundary
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Sat, 30 May 1998, Henrik Nordstrom wrote:

> Eric Stern wrote:
>
> > Just did. I would have earlier, but I spent the last couple of days
> > fighting with Async IO. Damn thing just wouldn't work. Finally, yesterday
> > I tried the "regular" 1.2beta20 distribution with Async IO, and it didn't
> > work either, so I guess its not my code!
>
> b20 had some minor troubles, but it did work most of the time. b21 works
> better. Make sure your libc is up to date (and pthreads library aswell
> if not using glibc)

It wasn't. I updated it and it works great now. Yes, I got squidfs working
with async-io, and it works fine. Zips right along.

> > Yes, thats true, it wasn't. But I don't see any reason why it shouldn't
> > work with Async IO. I had to rewrite disk.c and async_io.c a bit to make
> > it work (I made the queues work differently), but it wasn't that bad.
> > I'm a little skeptical about the benefits of async IO. I would have
> > thought that it would only help much in a multiprocessor situation. I
> > presume that is what you meant by scaling.
>
> No. MP was not on my mind. Keeping multiple disk spindles working was.
> Without async-i/o at most one disk can be reading at a single time and
> about one disk writing, which teoretically limits the disk speed to
> about two disk-spindles. But it also opens up the possibility to add one
> or two processors to drive the disk I/O load if needed, but only for
> disk I/O. Main thread is still limited to one CPU.
>
> Another nice effect of async-io is that when the load crawls up then
> multiple operations get queued on the same disk, and the OS begins to
> optimize in which order the I/O operations is done, which limits the
> in-total seek-times for high loads.
>
> > To be honest, the MAIN reason I like squidfs is the reduction in
> > filedescriptor usage. Anything else is just a bonus.
>
> If you are to support async-I/O you still have to use multiple file
> descriptors as you can't securely have more than one outstanding I/O
> operation per FD (shared file-offset amongs other things). Not even
> using readv/writev guards you against this.

Right. I had to rewrite disk.c to queue up read/write requests for each
FD. So there will only be 1 read or write operation in progress per FD at
any given time. However, there could be a read AND a write going at the
same time. If I read your comments correctly, you say this could be a
problem. I haven't had any trouble so far (its been a couple of days and
it has worked flawlessly, but my test machine isn't exactly heavily
loaded) but I'll watch for it. I could rewrite disk.c to use a single
queue for both reads and writes per FD, so only 1 op per FD would be in
progress at any given time, which would be "safe". This, however, may
impact performance. To get around this, I suppose you could setup multiple
swap files (ie if you have a 1gig cache drive, rather than 1 1gig swap
file, setup 4 250meg swap files). That would allow you to queue up 4 ops
on that spindle. As you say, the OS will optimize queued requests, but I
question the value of that in this application. Statistically speaking, I
get the feeling you'd rarely get much optimization, since the requests are
extremely random. However, we could try to emulate the seek optimizations
within squid, rather than depending on the OS.

I'm going to try to do some real testing this week. There are a bunch of
things I want to try. I only hope I can generate enough load on the test
unit to get meaningful results. :)

Things I'm planning to compare:
squid 1.1.21 (just for the heck of it)
squid 1.NOVM.21
squid 1.2.beta21
squid 1.2.beta21+async-io
squid 1.2.beta21+squidfs
squid 1.2.beta21+squidfs+async-io
and, depending on how that goes...
squid 1.2.beta21+squidfs+async-io+queue_optimization

It'll all be done on the same hardware, with the same set of URLs
(previously cached), so the results should be meaningful.

/-----------------------------------------------------------------------/
/ Eric Stern - PacketStorm Technologies - (519) 837-0824 /
/ http://www.packetstorm.on.ca /
/ WebSpeed - a transparent web caching server - available now! /
/-----------------------------------------------------------------------/

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:50 MDT