On Thu, Nov 02, 2000 at 02:31:53PM -0800, Jeff Mayzurk wrote:
>The model is exactly the same. In both cases you have a bunch of equivalent
>independent processes waiting for work from a single queue; and in fact
Not exactly the same... qmail-remote exits after every run. Do you have
any profile information that suggests that the fork latency is even worth
considering as far as making a performance impact? During heavy activity,
I'm not sure that the added complexity of the pre-fork code would cause
anything but a negative impact on the fork latency. Checking to see if you
have any spare workers and then forking is more expensive than forking
alone...
The first thing to do about this if you want to implement it is to
find out exactly WHY apache chose to do it that way. What were they
hoping to resolve with that, and did it actually achieve the desired
results?
The thing to keep in mind is that this scheme resulted in some fairly
poor benchmark results in one of the comparisons, because of the time
they took to ramp up to handling the full load.
>But certainly a component of this design would be to make the worker procesess
>persistent, i.e., they handle more than one connection before exit().
Actually, I suspect that ability to optimize the deliveries so that an
existing worker could be assigned multiple messages to a single host
would be the single biggest win -- especially in this day of a majority
of mail going to a handful of domains.
>The reason I'm in favor of this model is because (a) it's proven effective for
>very similar applications, hence the Apache reference; and (b) I believe it's
>possible to modify the qmail-send:qmail-remote interface to support this kind
>of model without completely ripping out the guts of qmail.
And what sorts of performance improvements do you expect to see? 1%?
3%?
>I really *don't* want to write a completely new MTA, particularly when qmail
>already does certain things very well. But there are definitely areas where
>performance can be improved.
It also does certain things particularly poorly. Injecting many messages
into the queue being the biggest issue. I don't have any complaints about
it the outbound delivery performance.
Sean
--
All bugs are shallow when there are many eyes looking for them.
VOTE! November 7, 2000
Sean Reifschneider, Inimitably Superfluous <[EMAIL PROTECTED]>
tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
