From: Thomas Duterme <[EMAIL PROTECTED]>
>I'm running a Dell 4300 (512 RAM, 4*9GB of Disk - queue sits
>on a 9GB partition, CPU=550Mhz PIII...)
(snip)
>We've got plenty of bandwidth at our colocation facility,
>(4Mb/s) so I don't believe that is the holdup either.
If you fill up a 9G partition with the queue, that means that you have about
9G to transfer. Over a 4Mb/s line, and if my 'rithmetic isn't wrong, even if
you filled completely the bandwidth that would mean at least 5 hours
(9e9*8/4e6/3600).
*But* you're using SMTP, and many sites (hotmail.com for one) take enormous
time to handle SMTP. This in fact reduces the usable bandwidth (again for
hotmail.com, around 600kb/s on a good day from Europe, in my experience).
You can increase parallelism (concurrencyremote) to try to send more mails
at the same time and optimize the bandwidth, but this only goes so far.
OTOH, you've got plenty of CPU and RAM, so clustering would be a waste of
the same.
Where I you, I would:
1) Setup additional qmail-queues in the same machine (using different disks
for each queue, so as to minimize seek time). All of those set to 240
concurrency local (requires trivial change on compiling qmail)
2) Change the dynamic Java thing to send to each queue in turn, and use
qmail-inject instead of SMTP (this avoids having to create as many SMTP
ports)
3) All bounces would be handled by a single qmail, of course
Note that your gain would still be limited by the bandwidth: 1 M messages of
that size a day requires more bandwidth or smaller messages.
Armando
