On Wed, 18 Aug 1999 13:21:52 -0400, Daniluk, Cris wrote:
>We want to speed the time it takes to inject mail into the qmail queue.
>Currently with smtp we can only inject ~500 messages per second. To speed
>this up, based on the recommendation of many on the list, I want to
>implement QMTP. Will the messages queued via QMTP be stored identically to
>those queued via SMTP? The messages will be received from the machine that
>generates the mails via QMTP, but it will still need to send via SMTP.
Yes, stored identically.
Look at qmail-qmqpc/qmqpd instead. If you have a good network (local
hosts, on phone lines, no sporadic interruptions between the hosts)
QMQP is excellent and all the programming has already been done for
you.
>Also, I know this thread has come up before, but what are the ramifications
>of bypassing the concurrencyremote limit of 255? This concurrency limit
>prevents us from being able to fully utilize 100mbit per network card in the
>machines. Running more qmails doesn't seem to be the most logical decision
>because we're already running 4 on the machine as it is (1 per nic). What
>would the damages by of doubling this hard limit?
We use P133/64MB/SCSI machines. Increasing concurrency from 255 to 500
gets a 60% increase in performance for lists with 15000 or so
recipients. It's not better since the box becomes processor/disk
limited. There is no difference in performance when concurrency is <
255, i.e. no penalty.
For your hardware, I'd expect a larger increase in performance up to
considerably higher performances (note that kernel 2.2.5 doesn't do it,
unless you have the ac>=3 patches. Don't know if later kernels support
this (earlier ones have a 1024 limit per process). What would be
interesting to know is the difference (assuming queues are on the same
drive) or 4 qmail installations of 250 each vs one with a concurrecy of
1000.
-Sincerely, Fred
(Frederik Lindberg, Infectious Diseases, WashU, St. Louis, MO, USA)
