> 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.
dbmail does this at the moment. Apache used to, when we used it some years ago. > > 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. When we used to use apache, we still needed php seperately installed. > > >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? > Experience. > > 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. No the other way around, as long as one isn't forced to code strict the code will tend to be sloppier, and contain more bugs. > 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. That is basically not true, I've written them however not in C but in pike. They have brought me much performance gain in data handling. However the project is not the same as dbmail (as in much smaller). memcached sounds nice, but I think developers (I'm not one off them so I just give my thoughts and don't want to force anything!) should not see it as the sollution to everything, and forget other optimization that can ben done. Threading has no issues but as was stated does need a complete redesign. Eventually developers have to decide if it is worth it, but I do see a gain here. > > Anyway, I'm done repeating myself, at this point I should either get > quiet or start writing code ;-) We both talk about what we think is best for dbmail future, open discussion is always a good thing. Marc _______________________________________________ Dbmail-dev mailing list [email protected] http://twister.fastxs.net/mailman/listinfo/dbmail-dev
