Hello,

I'm trying to learn about writing high performance servers, and I have a
few questions not clearly answered by any documentation I can find. I'm
comfortable with select(), poll(), and kqueue(), but that only goes so
far. I'm currently looking into how to send static files (over a
network) with the least amount of overhead.

There was a post [1] on misc@ asking about the status of a sendfile()
call, but nobody replied (and it seems that splice(2) and tee(2) are
just GNUisms). It appears that there's been some work on socket splicing
(see sosplice() in [2]), but there's still no sendfile (or if it's
there, I must not be looking in the right place [3]).

If I want to serve a bunch of files often, is it fine to rely on the
kernel's filesystem caching? or should I mmap() them into my address
space and madvise() them to not be swapped out? Is it reasonable to
stat() the file each time it is served (from my cached copy) to compare
the file's modification time to the time it was cached? Would this
actually hit the disk each time? or does the kernel keep that cached?

It seems obvious to me that it should be be cached, but I can't actually
find the relevant code. I spent a while digging through the kernel, but
I don't really know where to look, and I'm not sure I'd recognize what
I'm looking for if I found it anyway. The closest thing I found to
something I think might be relevant was some cryptic vfs stuff. :( I'm
no kernel dev, I don't pretend to understand OpenBSD internals nearly as
well as I'd like to.

Lastly, What's the OpenBSD community's current opinion on libevent /
libev. Are they secure / stable enough that they should be considered
for new code in base? Are they worth using instead of just using
select/poll/kqueue/event(3) directly?

[1] http://marc.info/?l=openbsd-misc&m=112690025715479&w=2
[2]
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/kern/uipc_socket.c
[3] http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/sys/kern/syscalls.c

Many thanks for any and all advice,
Jean-Philippe Ouellet

Reply via email to