At 10:19 AM Friday 4/9/99, [EMAIL PROTECTED] wrote:
>qmail-inject is too slow. I've been using qmail-queue instead.
Only because you're doing an invocation per recipient! I'm guessing, but I'm
almost certain the qmail-qstat will show some interesting numbers.
Particularly "messages in queue but not yet preprocessed" value.
What's particularly killing your system is the message injection process.
>On Fri, Apr 09, 1999 at 05:01:48PM -0000, Lorens Kockum wrote:
>> On the qmail list [EMAIL PROTECTED] wrote:
>> >
>> >You can. Just make sure that you send a single email, with a CC list
>> >of size 200K. Then you can get performance comparable to spammers.
>>
>> Just for the sake of discussion, what would be the best way?
Use qmail-inject with multiple Bcc: recipients as suggested a few days ago.
Since the invocation happens just the once for the all recipients, there is
no advantage to using qmail-queue (and some disadvantages if you ask me).
On the matter of comparison to spammers, here's what you need to do to get
comparable results:
1. Turn off all disk I/O
2. Ignore the SMTP transaction
3. Don't care if a recipient sees the mail zero or more times
4. Ignore system and network failures
If you want to go part way down this path I suggest putting /var/qmail/queue
on a memory-based file system rather than twiddling fsync() calls in the code.
FWIW. The best I've seen out of a single box Pentium with one or two high
speed spindles is around 100K per hour. The systems tend to run out of queue
disk I/O. (This of course is gross generalization as most people will
realise, but it gives a ballpark expectation for an unmodified qmail system).
>> I'm envisioning using xargs to distribute the rcpt addresses to
No point. Put the recipients in bcc: headers and only invoke qmail-inject
the once.
>> qmail-inject, which would nicely create one message-instance
>> for every n recipients, but I haven't quite figured out how
>> to get the mail itself on the stdin of qmail-inject without
See the example I posted the other day.
Regards.
