> Leif Jackson wrote: > >>>Could you please explain how Oracle's connection overhead directly >>>translates to we need threads? A new thread still has to open up a new >>>connection to the DB. It sounds to me that Oracle's connection overhead >>>(or Postgresql or whatever) is more an argument for persistent >>>connections and pre forking more than threads. But if I'm missing >>>something please let me/us know. >>> >>> >> >>I know a good bit about oracle (and maybe re-writing a new driver for it) >>but that wasn't my driving force behind the code work... as for my >>implementation it uses thread pool's and so it only opens a connection >> the >>first time a thread is used then it keeps that connection open in memory >>for the next client and then closes all of them (up to MAXCHILDREN) at >> the >>end of the life of the daemon. >> > > Ok, so you are using thread pools to implement persistent connections. > I would still like to hear more details about the "60% speedup" of the > threaded pop3 daemon vs the non-threaded. Exactly what was 60% faster? > I still think that the Multi-Process Model can be just as effective as a > threaded model with the benefit of simplified code.
Yeah, the overhead of fork and not having to have shared memory segments is where i see the speedup. I belive the rest of the speedup comes from chaning out Glist and some other things. But I have some neat things up my sleave..etc. I accualy think I just found a faster mime parser that is GPL'ed than GMime. it is stable and well tested as well as thread-safe which GMime may or maynot be acording to thier docs...etc. I will see what I feel like when I get to that point.. :) The other library is called EPS: http://www.inter7.com/index.php?page=eps I guess the mime stuff is a RFC...etc. > > BTW, I'm not trying to be negative about your work, I'm just trying to > discuss the options and get down to the real details. I don't want us > making radicle changes without good well thought out, discussed and > agreed upon reasoning. Yeah I know not thinking that at all, I am doing it for someone else weather or not the dbmail developers decied to use any or all of it. So it works out for all of us :) You can thank my customer more they are the ones paying me to fiddle with it :P Thanks, Leif > > Thanks for the hard work! > > Matthew > > > _______________________________________________ > Dbmail-dev mailing list > Dbmail-dev@dbmail.org > http://twister.fastxs.net/mailman/listinfo/dbmail-dev >