[ Moved to dbmail-dev as Aaron suggested ]
Marc Dirix wrote:
threading is more controllable during a DoS attack.
I've never heard this before, please expound.
When using a monolithic threading model, the socket is only opened to
the main thread. This main thread will create handler threads if someone
sends data to the socket. In this model all new connection are handled
sequentially, however the return values can be asynchron from each
thread.
The main thread can easily manage both traffic shaping/limiting and
drop multiple connects from the same client.
This against a multi-process model where there are x default handlers
trying to beat eachother to the socket when a client connects. There is
no control whatsoever about the socket.
I'm not aware of any well written multi-process model where there are x
handlers competing with each other for connections. The service I'm
most familiar with is PostgreSQL which is multi-process and will never
go multi-threaded. They have one process (the postmaster) which listens
and fires off (forks) additional backends that actually do the work.
threading if done right, will provide better scaling abilities (see
roxen versus apache).
I don't know much about roxen, but I think lots of things will scale
better than Apache since Apache by design is a kitchen sink type program.
That is actually the other way around. Apache is a webserver. If
scripting or whatever is needed one has to look for external compilers
like php or perl. However Roxen is a webapplication server, it has a
internal (RXML) parser which can do just about everything you need for
dynamic pages. (And also if needed interface to php/perl).
Yes and no: Yes apache needs external handlers, but those handlers are
written as apache modules, so from the perspective of load, most Apache
servers have everything including the kitchen sink linked in.
The problem with apache is in the fact that to be able to handle N
connects it has to create N childs which eventually will limit to a
maximum. This doesn't scale well. A model where only one socket exists
and connections are handled sequential will scale very well until system limits
that is.
What is this assertion based on?
threading will provide us eventually with a more sleak and clean design,
because it does not allow for the apache programming model in the sense of:
"We have this child, it leaks memory so lets kill it after x connects en
start a new one."
This sounds like a threads are better because they are argument. The
benifit of being able to kill off a process with memory leaks is that
the server still runs, if you have the same memory leak in a treaded
app, you have to restart the whole server.
That's the sloppy programmers kind of view. "We know we leak, but
instead of fixing it we will kill our children".
I'm an not advocating not fixing our problems, I am being pragmatic.
Bugs in software exist, DBMail will never be bug free, we should and
will always search to find and close any bug we find, but even so, there
will be leaks at times. The multi-process model where your child
processes get killed off after a while is a more stable design.
I'm not against threading, I'm just concerned that we are going to add a
ton of complexity for very little gain.
That is true, it will take a steep programming curve to do right.
And sure it will take a long time before dbmail is back to the current
level, however now is the time to make such a decission not after
putting another year of effort into 2.3. The next chance would only be
after 2.4 release.
I know I sound like a broken record, but all I'm seeing here is a bunch
of hand-waving from people saying, "yes threads are complex, and yes
we've never written a threaded app before but threads are better
because, well because they are.". I personally think the memcached
stuff sounds interesting, it might allow us to scale quite a bit and
greatly reduce database load without any of the threading issues.
Anyway, I'm done repeating myself, at this point I should either get
quiet or start writing code ;-)
Matt
_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev
