Markus Stumpf wrote:
>
> On Thu, Nov 02, 2000 at 02:54:10PM -0700, Sean Reifschneider wrote:
> > That's the problem. It's relatively slow throwing a bunch of messages
> > into QMail. It doesn't take a very powerful machine to completely swamp
> > a fairly hefty QMail server, I've found.
>
> I think the main problem is within qmail-send.
> qmail doesn't use concurrencies to their max as long as there are still
> unprocessed messages in the queue or the deliveries generate a lot of
> bounces.
This sounds like a bumber for what I want it to do ...
> We have a customers that injects about 15000 single messages in bunches
> of 100 messages to a dedicated qmail server. Sadly the "list" isn't too
> well administrated and even after the queue has reached a status where
> you have no unprocessed messages at one point the bounces slow down
> qmail quite a lot.
> I have generated a graph from the
> qmail: 973205710.228381 status: local 0/120 remote 1/120
> lines which show this "waving" behaviour. I'd posted that info to the
> list some time ago, but anyway, here's the URL for that graph (10 KB) again:
>
> http://www.lamer.de/maex/creative/software/qmail/deliver-stats.gif
>
> The lot of local deliveries are due to the QUEUE_EXTRA delivery we have
> for accounting reasons.
>
> I have made a second graph. This is also a dedicated qmail server
> running a mailinglist (newsletter) with approx 91000 subscribers.
> The graph is one "shot". As the mailing-list is run by ezmlm there are
> very few bounces and only some occasional (un-)subscribe messages.
> This time qmail keeps the concurrency at max. The second and third
> shorter peaks are due to deferred messages tried again after backoff.
> The image (40 KB) is at
>
> http://www.lamer.de/maex/creative/software/qmail/deliver-stats2.gif
>
> I know it would be better to also have some figures about messages
> in queue, unprocessed messages in queue, successful/deferred deliveries
> included, but those are hard to extract from the logfile :/
>
> I think a big gain in performance would be to split up the scheduler
> in qmail-send into at least one for remote, one for locals and one
> for sorting in new messages into the remote or local queue.
These graphs were quite interesting - and seem to backup evidence that
I've seen (in that concurrency remote is not hit untill injection
stops).
Assuming an outbound machine is being used (and another machine for
inbound / bounces)
Hence to improve performance inject should be split up i.e inject 2000,
wait, inject another 2000. In the wait times concurrency remote would
be reached.
Any ideas on what a good number to try would be for inject / wait cycle
?
Also is changing the scheduler easy ?
Interesting stuff - thanks.
Greg
>
> \Maex
>
> --
> SpaceNet GmbH | http://www.Space.Net/ | Stress is when you wake
> Research & Development | mailto:[EMAIL PROTECTED] | up screaming and you
> Joseph-Dollinger-Bogen 14 | Tel: +49 (89) 32356-0 | realize you haven't
> D-80807 Muenchen | Fax: +49 (89) 32356-299 | fallen asleep yet.
