> 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

Reply via email to