Mailing List Archive: qmailanalog results

qmailanalog results

evanc at synapse

Mar 22, 1997, 10:11 AM

Post #1 of 11 (1150 views)

I was playing around with qmailanalog and decided to share some of my
results. I'm not sure if I'll get any deeply meaningful discussion about
them, but I thought I'd give it a try :-) I'm not sure if I am analysing
some of the numbers correctly so I'd be very interested in any help there.

These are some of the results for yesterday, an average day with no major
mailing list traffic, and for the day before, where 3 or 4 messages were
sent to my 40K user mailing list (but otherwise an average day).

no mailing list mailing list
Messages 10139 12422
Delivery Attempts 19117 155438
Average xdelay 13.5604 22.5135 seconds
Average ddelay 56.6633 6405 seconds
Average concurrency 3.00251 40.4903

10% messages doneby (seconds)
absolute 0.22 100.29
average 0.21 20.28

50% messages doneby (seconds)
absolute 0.47 6391.85
average 0.27 2099.18

90% messages doneby (seconds)
absolute 113.27 11943.10
average 7.55 4170.89

One can sort of see that a large mailing list puts quite a different load
on the system than individual traffic. The delivery times without the
mailing list running are excellent.

On the mailing list, the average delivery time is getting very skewed
because it takes so long to run through the list. In addition, during
this time no other deliveries are taking place. Since qmail handles the
mail on a first-come-first-served basis, if the mailing list sends 3
messages in a row, and it takes, say, 2 hours to run through each message,
no other deliveries are going to be made for 6 hours! IMHO, some sort of
mechanism to allow other queued messages to be delivered promptly should
be a top priority.

The time to deliver the list, however, looks pretty good. It's about
43000 users, and from the qmailanalog results it looks like it's
delivering it mostly in well under 2 hours (there's just the few dead
sites etc. that push up the results.) The list, BTW, is being maintained
by qlist with outgoing mail going through Majordomo's resend to handle
moderation. Majordomo itself was much too heavy to run for
subscribe/unsubscribes for this particular list, though I still use it for
my other lists. I'm really itching to try out ezmlm.

This machine is a Pentium-90 with 128 MB RAM (32 MB of which is BUFMEM),
concurrencyremote 255, with a single Barracuda 2LP fast/wide disk and
BSD/OS 3.0. I'm on a T1. Nothing terribly fancy. Can you imagine how
this same configuration used to run with sendmail? :-)

Evan

Re: qmailanalog results [ In reply to ]

nowhere at chaos

Mar 22, 1997, 10:47 PM

Post #2 of 11 (1151 views)

On Sat, 22 Mar 1997, Evan Champion wrote:

>One can sort of see that a large mailing list puts quite a different load
>on the system than individual traffic. The delivery times without the
>mailing list running are excellent.

Note that my statistics are very similar to yours. I auto-run qmailanalog
on my qmail logs (25-50MB per day) daily. My mailing lists are around 2K
subscribers and I find that 99% of messages are delivered in 22 minutes on
average, but that last one percent pushes delivery delay time up to 8
hours.

>On the mailing list, the average delivery time is getting very skewed
>because it takes so long to run through the list. In addition, during
>this time no other deliveries are taking place. Since qmail handles the
>mail on a first-come-first-served basis, if the mailing list sends 3
>messages in a row, and it takes, say, 2 hours to run through each message,
>no other deliveries are going to be made for 6 hours! IMHO, some sort of
>mechanism to allow other queued messages to be delivered promptly should
>be a top priority.

YES! YES! YES! I am begging for a feature that would immediately deliver
non-bulk, non-list mail (i.e., no Precedence header or a first-class one
like "normal" or "high.") When my lists get a burst of traffic or I am
forced to reboot the system during prime time, it can take up to an hour
to deliver my personal mail. On the old system (486) it was almost a day
at one point.

>concurrencyremote 255, with a single Barracuda 2LP fast/wide disk and
>BSD/OS 3.0. I'm on a T1. Nothing terribly fancy. Can you imagine how
>this same configuration used to run with sendmail? :-)

I never got messages about list performance that were good before
switching from sendmail to qmail. Now I regularly get comments from
people who are impressed at how quickly they get their postings back from
the list (average 10 minutes.) These are things that are hard for me to
guage since they're in my mailbox in 2-3 seconds. :-)

Chael

--
Chael Hall, nowhere@chaos.taylored.com

Re: qmailanalog results [ In reply to ]

Mar 23, 1997, 12:37 AM

Post #3 of 11 (1143 views)

Chael Hall <nowhere@chaos.taylored.com> writes:
>On Sat, 22 Mar 1997, Evan Champion wrote:
>>IMHO, some sort of mechanism to allow other queued messages to
>>be delivered promptly should be a top priority.
>
>YES! YES! YES! I am begging for a feature that would immediately deliver
>non-bulk, non-list mail (i.e., no Precedence header or a first-class one
>like "normal" or "high.") When my lists get a burst of traffic or I am
>forced to reboot the system during prime time, it can take up to an hour
>to deliver my personal mail. On the old system (486) it was almost a day
>at one point.
>

Have either of you guys considered the suggestion I made a week
or two ago about feeding list traffic to a second qmail setup?

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

Re: qmailanalog results [ In reply to ]

evanc at synapse

Mar 23, 1997, 10:21 AM

Post #4 of 11 (1145 views)

Chael Hall wrote:
> YES! YES! YES! I am begging for a feature that would immediately deliver
> non-bulk, non-list mail (i.e., no Precedence header or a first-class one
> like "normal" or "high.") When my lists get a burst of traffic or I am
> forced to reboot the system during prime time, it can take up to an hour
> to deliver my personal mail. On the old system (486) it was almost a day
> at one point.

Yes, doing some sort of Precedence handling would be very nice for this
sort of thing. But even a timer would work well, and should require
only minor changes.

Dan, what do you think about that? It seems to be something that a lot
of us are interested in, and I don't think a simple timer would
compromise qmail's design in any way.

Evan

Re: qmailanalog results [ In reply to ]

evanc at synapse

Mar 23, 1997, 10:24 AM

Post #5 of 11 (1141 views)

Greg Andrews wrote:

> Have either of you guys considered the suggestion I made a week
> or two ago about feeding list traffic to a second qmail setup?

That was something I asked about a few weeks ago but didn't hear
anything back on. That would certainly be sub-optimal, and I think
qmail really should be fixed so that this isn't an issue, but while
we're waiting for someone to make a patch it might be a good idea.

If you still have a copy of that message, could you send it to me again?
If not, I'll start digging through the archives.

Evan

Re: qmailanalog results [ In reply to ]

richard at illuin

Mar 23, 1997, 11:07 AM

Post #6 of 11 (1145 views)

On Sun, 23 Mar 1997, Evan Champion wrote:

> Chael Hall wrote:
> > YES! YES! YES! I am begging for a feature that would immediately deliver
> > non-bulk, non-list mail (i.e., no Precedence header or a first-class one
> > like "normal" or "high.") When my lists get a burst of traffic or I am
> > forced to reboot the system during prime time, it can take up to an hour
> > to deliver my personal mail. On the old system (486) it was almost a day
> > at one point.
>
> Yes, doing some sort of Precedence handling would be very nice for this
> sort of thing. But even a timer would work well, and should require
> only minor changes.

If it only requires minor changes, why don't you write a patch that will
do it, and share it with everyone else?

I know we all bow down before the awesome coding abilities of Dan,
but let's start writing the bits ourselves that qmail doesn't do
to our satisfaction and smooth the rough edges.

RjL
+----------------------------+
| richard@illuin.demon.co.uk | Aut viam inveniam aut faciam
+----------------------------+

Re: qmailanalog results [ In reply to ]

Mar 23, 1997, 3:02 PM

Post #7 of 11 (1141 views)

Evan Champion <evanc@synapse.net> writes:
>Greg Andrews wrote:
>
>> Have either of you guys considered the suggestion I made a week
>> or two ago about feeding list traffic to a second qmail setup?
>
>That was something I asked about a few weeks ago but didn't hear
>anything back on.
>

I didn't see that request. Hmm.. wonder if my local e-mail (sendmail,
not qmail) is missing messages intermittently.

>
>If you still have a copy of that message, could you send it to me again?
>If not, I'll start digging through the archives.
>

My message didn't go into detail about how it would be done.

After thinking about it for only a few minutes, here's what comes
to mind:

o Set up a second set of qmail uids. This might not actually be
necessary, but would reduce any admin confusion that might arise
from two sets of daemons running simultaneously.

o Compile and install a second set of qmail binaries that use the
second set of uids, and, more importantly, use a different queue.

o Configure your list manager to use the second qmail-inject rather
than the original one. Non-list mail still uses the original qmail.

Since the list mail goes into a different queue, it won't block "normal"
mail's access to delivery slots.

Unless you can handle very high concurrency levels, you'll probably
want to set the concurrency for the list deliveries fairly low, to
allow "normal" deliveries to take precedence.

Hope this helps,

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

Re: qmailanalog results [ In reply to ]

evanc at synapse

Mar 23, 1997, 3:08 PM

Post #8 of 11 (1150 views)

Greg Andrews wrote:
> o Set up a second set of qmail uids. This might not actually be
> necessary, but would reduce any admin confusion that might arise
> from two sets of daemons running simultaneously.
>
> o Compile and install a second set of qmail binaries that use the
> second set of uids, and, more importantly, use a different queue.
>
> o Configure your list manager to use the second qmail-inject rather
> than the original one. Non-list mail still uses the original qmail.

It seems like all one would need to do would be to change CONF_HOME in
conf-home.h and then just setup a physically separate qmail install.

Evan

Re: qmailanalog results [ In reply to ]

nowhere at chaos

Mar 23, 1997, 3:51 PM

Post #9 of 11 (1142 views)

On Sun, 23 Mar 1997, Greg Andrews wrote:

>Since the list mail goes into a different queue, it won't block "normal"
>mail's access to delivery slots.
>
>Unless you can handle very high concurrency levels, you'll probably
>want to set the concurrency for the list deliveries fairly low, to
>allow "normal" deliveries to take precedence.

On the contrary, the concurrency level for "normal" mail could be low
(5-10 maybe) and that for the list mail would be very high. The point is
to attempt the delivery right away. Evan and I both have fast links, so
that's not a limiting factor.

Chael

--
Chael Hall, nowhere@chaos.taylored.com

Re: qmailanalog results [ In reply to ]

Mar 23, 1997, 7:30 PM

Post #10 of 11 (1140 views)

Chael Hall <nowhere@chaos.taylored.com> writes:
>On Sun, 23 Mar 1997, Greg Andrews wrote:
>>
>>Unless you can handle very high concurrency levels, you'll probably
>>want to set the concurrency for the list deliveries fairly low, to
>>allow "normal" deliveries to take precedence.
>
>On the contrary, the concurrency level for "normal" mail could be low
>(5-10 maybe) and that for the list mail would be very high. The point is
>to attempt the delivery right away. Evan and I both have fast links, so
>that's not a limiting factor.
>

But that would decrease the concurrency-induced latency for list
traffic, and increase it for non-list traffic. Isn't that the
opposite of what you wanted?

-Greg
--
Greg Andrews West Coast Online
Unix System Administrator 5800 Redwood Drive
gerg@wco.com Rohnert Park CA 94928
(yes, 'greg' backwards) 1-800-WCO-INTERNET

Re: qmailanalog results [ In reply to ]

evanc at synapse

Mar 23, 1997, 7:52 PM

Post #11 of 11 (1141 views)

Greg Andrews wrote:

> But that would decrease the concurrency-induced latency for list
> traffic, and increase it for non-list traffic. Isn't that the
> opposite of what you wanted?

Not really. We're not trying to combat concurrency-induced latency on
non-list traffic. We're trying to combat
message-stuck-in-queue-while-list-running-induced latency :-) which is
about 5 orders of magnitude more :-)

Getting mailing list traffic out as fast as possible under any
circumstances is the ultimate goal because you need to get 1 message out
to do the next message going out to the list. I don't like being on
mailing lists that take days to deliver things, and I wouldn't want to
put that on my customers or their subscribers, and that's exactly what
would happen if I tried to run my 40K user list with
concurrencyremote=10.

Evan