On Mar 17, 10:01pm, "Michael O'Reilly" wrote:
} Subject: Hmmmm.
}
} The bulk of the wall clock time tho is used in unlink, read, and open,
} which account for about 67% of total elapsed time!
}
} The main problem seem to be the synchronous I/O waiting for disk,
} amplified but the fact that only one disk queue is getting used.
This is exactly what makes the NOVM version of squid non-viable in my
opinion. I think a hybrid approach is probably the way to go.
} I had some thoughts about have an apache style model, which multiple
} processes using mmap() to share the index, and locking to share the
} accept()'s. Anyone looking at this? It'd be a lot more portable than
} the async disk I/O I see some people looking at...
Also, async I/O probably only helps read(), which is consuming less time
than open() and I haven't seen an async open(). If you are serious about
async I/O, probably the best approach would be to use a raw partition like
the database folks do.
--- Truck
Received on Tue Mar 18 1997 - 14:47:42 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:34:43 MST