Hi folks,
I've seen the answer to this question before, but it escapes me now. :-)
I've gotten to the point (with help from the "How well does Exim scale?"
FAQ entry[1]) where my mass mailing server is processing the queue at a
sustained rate of over 37,000 messages, at a FreeBSD load average of
0.4. Needless to say, I'm impressed. :-)
The problem isn't with delivery, but with queuing. Currently, I'm
queuing less than 3 messages a second [2]. Part of this has to do with
some fairly intense interaction with a database for the sake of
personalization. However, I'm pretty sure that I could improve on this
dramatically if my queuing strategy didn't involve piping messages into
one-time instances of
exim -odq -f <sender_addr> <recip_addr>
For some reason, I thought I remembered batched SMTP being a solution,
but looking a the spec, it look like it's the solution to the other side
of my problem, which is already solved.
So... What's the accepted "very fast, but kinda dangerous if you're not
careful" approach I'm almost sure I remember being discussed?
Ciao,
Sheldon.
[1] I used the approach described where a cron job controls the number
of queue runners. When the queue is small, all that happens is a
short-lived queue runner is launched every 30 seconds. When the
queue is _not_ small, the job gradually scales up to some upper
limit of queue runners. I'm using 190 at the moment.
[2] Delivery faster than queuing? Huh? Well, I allowed bad DNS
configuration and sub-optimal queue running to grow the queue to
about 70,000 messages before tackling the problem.
