1. We use multilog with option t s2500000 to the /var/log/qmail/qmail-send
and /var/log/qmail/qmail-smtp (same hard drive and partition) - exactly same
as mentioned in Adam McKenna's qmail-HOWTO v2
2. The test setup was run exactly same as the production; the only
difference was the email- ids were non-existent.
3. Well, I think I misunderstood "sending unique mails Vs sending same mail
to different addresses". Well, the application sends unique mails to
different addresses with the same contents (the header changes each time
since the "rcpt to:" changes in each mail, the body remains same)
4. I have applied the big-todo patch and set the conf-split to 40, we will
be running the test later today. (Well, I am not sure whether I have applied
it correctly - though I can see the todo directory having 40 sub
directories)
The only thing I can see now is the disk bandwidth problem, I will have to
test it with better disks.
Many thanks again for replying. I greatly appreciate the same.
Regards,
Mehul.
-----Original Message-----
From: Charles Cazabon [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 19, 2001 12:26 PM
To: Qmail (E-mail)
Subject: Re: Queue Building
Mehul Choksi <[EMAIL PROTECTED]> wrote:
> Thanks a lot for the reply.
You're welcome. However, in future, could you set your email client up to
use
standard quoting conventions? The way you quoted my message made it
extremely
difficult to read and determine which parts you had added. I've fixed the
quoting for this reply.
> > Do you mean send identical copies of one message to a million users, or
send
> > one million unique emails, each to one user? The difference is
enormous.
> It depends, normally in batches of 100,000 to 300,000 identical mails
> prepared by an application to be sent to subscribers. Currently we use a
> pool of sendmail servers (ordinary PIII 500 with 128MB RAM and IDE). We
are
> planning to migrate to QMAIL eventually if we find better performance.
100,000 recipients each for 10 unique emails a day is trivial to do with
qmail. However, your testing didn't actually test this. You sent thousands
of unique messages to one or more recipients each, which is a completely
different (and more difficult) queue load. Change your testing methods, and
you'll see the difference.
> > You may be running into a queue disk bandwidth limitation. What sort of
> > hardware are you using? Is the queue on a disk by itself? Is that disk
a
> > 15kRPM SCSI disk, sitting on its own U160 controller? Is that
filesystem
> > mounted noatime? What filesystem are you using? What OS?
> >
> > How are you logging? What does the system load reach while running your
> > injection? Have you read the section on large servers at www.qmail.org?
> > Is /var/log on a separate disk?
> The server we are using is a very ordinary machine with PIII 500, 128MB
> and an IDE on Red Hat Linux 6.0 with upgraded kernel. Logging is done
> exactly the same way mentioned in the HOWTO.
I'm not familiar with the HOWTO you speak of. Does it use splogger to send
the logs through syslog? If that's the case, syslog could be eating 90% of
your CPU and 90% of your queue disk bandwidth, if the /var/log is on the
same
filesystem as /var/qmail/queue. You didn't answer any of these questions;
we
can't help you if you refuse to answer them.
Basically, you want to ensure you're logging through multilog, not splogger,
and sending the logs to a separate disk than the queue is on, for maximum
performance.
> We will distribute the load of SMTP using the LVS. The same test we ran on
> sendmail with the very similar machine was acceptable - sendmail didn't
> build up a huge queue - it processed all the mails. However, It was rather
> slow in accepting the message though.
But sendmail can be configured to try delivering the mail before queuing it;
this is unreliable and can result in lost mail. We know nothing of your
sendmail configuration (and probably don't want to know).
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <[EMAIL PROTECTED]>
GPL'ed software available at: http://www.qcc.sk.ca/~charlesc/software/
Any opinions expressed are just that -- my opinions.
-----------------------------------------------------------------------
