> Leif Jackson wrote: > >>>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. >> >> > Interesting, I look forward to hearing about this new parser. I'm sure > there is room for improvement in our parsing routines.
Going over it with dmalloc now to see if it is even worth the effort so far not bad :) Very fast on it's test mails going to feed it junk in a bit, Anyone on the list have the e-mails that dbmail used to barf on in a tgz they could send me for testing? > > While the overhead of creating a new thread is less than the overhead of > calling fork, I still don't think this will buy us much since the fork > call typically doesn't account for a significant percentage of the work > done after connection, and even if it did, preforking can handle a lot > of this. Again there is a distinction between the workload a light http > server that doesn't to much thinking vs. an IMAP server that does a lot > of work during the average connection so as to make the fork overhead > negligible. Maybe as everyone has said the proof will be when others try my patches as I have seen a drastic improment in the pop3 code, and as I have said i am not totaly done with imap. > > As for the overhead of shared memory segments, I claim no expertiece > here, but I'm surprised to hear that this is a performance bottleneck. > Are you sure? Well not to take anything away for paul's great work! (thanks paul for the pre-fork stuff btw! ) I have seen on my test bed that the attach and detach way that it is currently done in dbmail is a bottleneck for number of simultanious connections but not throughput. > >>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 >> > Well I would think I speak for the whole community when I say that we > would like to benefit from you work :-). One general comment which I > think was alluded to earlier in this thread. If you want to get some of > this applied, I think it best to separate out different parts of the > patch. It may not make sense for you right now if you are trying to > throw together a proof of concept but in the long run all the GMime > changes etc, should probably be made separate from the threading changes. Yeah understood, definaly not somthing I can do right now. Maybe once I am to a testing point for the public (dbmail-dev) someone can take on that task as I am not sure I will have the time. Thanks, Leif
