[Date Prev][Date Next]
Re: Benchmarks at Network World
"Booker C. Bense" wrote:
> - Unless there has been a drastic reengineering since the Umich3.3
> days, slapd without threads would be a single process server. It
> wouldn't even benefit from the OS level parallelism of the subprocess
> forking model. Basically the code used a "thread" abstraction at the
> server level that just ran the whole thing in a single process if
> there was no support for threads in the underlying OS. It has been
> quite a while since I looked at that part of the source, but I
> remember thinking at the time that it would be very difficult to
> modify it to use the standard unix fork/exec model of server.
Absolutely correct, that's the way it works.
> > Any idea on what might be producing that? Besides saturation on the
> > client side, of course, that I will presume for now it is not the
> > case.
> - This is exactly what I would expect without native OS threading
Can you explain this? Wesley Craig has suggested a way for it to happen,
but I think it can only be seen with real, preemptive threads.
> Unless openldap has reengineered the slapd server to support
> the standard unix fork/exec model, it's basically useless on a
> platform that does not support native OS threads.
Especially, on mutiprocessors (notice that the test platform was
a 2-CPU server).
> I suspect Openldap
> on linux is never going to win any speed contests due to linux's
> thread model (threads are processes).
It is not as bad as you paint it. Threads are *not* processes on
Linux. Both processes and threads are particular cases of the same
underlying concept (a clone). The difference is how much you share
from the parent on clone creation: processes share little besides
file descriptors, while threads share nearly everything. If you
call clone() yourself, you may implement your own model. Thread
creation is little more than allocating a new task descriptor and
copying memory mappings. Don't let be fooled by threads having
different PIDs. Thread creation does not have the overhead of
forking. Or at least, it is not supposed to be.