Hi Dirk,
I tried the no_fsync method last night and recorded a 10% speed improvement.
At 07:27 AM 4/9/99 -0700, [EMAIL PROTECTED] wrote:
>On Fri, Apr 09, 1999 at 08:44:06AM -0400, Dave Sill wrote:
>> When you're sending messages, how many qmail-remotes are running?
>
>About 90-130. 255 if I stop delivery for a little while and then restart
>it. To me that means that the machine can send faster then I can get the
>messages into the queue.
In my experience (also sending huge amounts of unique emails) the
bottleneck in qmail (for this application) is the queuing system. Look at
your todo dir and I bet you'll see thousands of entries there in a single
directory (R. Nelson has a patch to split this directory, but it still
didn't do what I needed).
As long as some messages are waiting to be "preprocessed" (see INTERNALS
for explanation), qmail does not achieve 255 simultaneous qmail-remote.
Besides, as you inject the messages into the queue, qmail-send spends a
huge amount of time cleaning up (via qmail-clean). It seems to me that
qmail-send gets too busy preprocessing and cleaning up and has no time to
send the emails as fast as they come.
Obviously, djb didn't think qmail would be used this way. If he had, why
would he have left the todo and intd directories flat?
Also, from THOUGHTS:
>qmail-send doesn't have any notions of precedence, priority, fairness,
>importance, etc. It handles the queue in first-seen-first-served order.
>One could put a lot of work into doing something different, but that
>work would be a waste: given the triggering mechanism and qmail's
>deferral strategy, it is exceedingly rare for the queue to contain more
>than one deliverable message at any given moment.
The triggering mechanism is the select() call on lock/trigger. That works
well, but I still have 10000 messages waiting to be preprocessed!
Everybody says:
> buy this or that, faster disks, RAM disks, scsi, ....
Of course buying more, better hardware will improve performance, but I
still think an architectural change on the way qmail-send preprocesses and
then sends emails would be better (why not 2 processes: qmail-preprocessor
and qmail-send?). Spending more money when other solutions can be made
available is not a good solution.
What I'd like is the opposite: *saving* money while improving (or
preserving) performance!
I'd love to hear suggestions.
>> >Is qmail 2.0 out?
>>
>> No, but it promises dramtically improved queue performance.
Yes, zeroseek technology. We are all impatiently waiting for it.
David.
