[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Newbie: Slow scheduling?
> Hi, I'm using Zmailer 2.99.50-s19, and everything seems to work, but I've
> noticed that it's a bit slow:
>
> Jun 29 09:36:00 calix router[2257]: S.rS5RM104048:
> from=<dani@calix.enpl.es>, rrelay=dani@localhost size=327, nrcpts=1,
> msgid=<19990629093552.A2361@calix.enpl.es>
> Jun 29 09:36:10 calix mailbox[2367]: S.rS5RM104048: to=<dani>,
> delay=00:00:18, xdelay=00:00:00, mailer=local, stat=ok3 Ok
>
> I don't understand those 18 seconds of delay (sendmail usually gives 0-1
> seconds..). This delay goes from 7 to 30 seconds.. I'm I doing something
> wrong? I'm using bind-8.1.1 as the nameserver. And I'm using zmailer in a
> Sparc Ultra 1 and a PPro 200 (same results).
Yes and no. Sendmail is monolithic program doing all by itself
from message submission to driving the final delivery.
Thus sendmail is fast for doing its job, but on the other hand,
when there is *lots of* separate emails to deliver, you can all
the sudden have lots of running 'sendmail' processes, and then
your system load skyrockets without limits...
ZMailer is designed around separate servers which do their parts
of the job, and pass the task along to next one. This comes in
part from security desire of not letting user started program
to do routing and (worst of all) final delivery.
ZMailer's components check for new jobs only every about 10 to
20 seconds, or so. With multiple routers running that first
step delay often pretty much disappears, but the scheduler is
a single thread program and as such its scan interval in "new-job"
directory checks does show up. Then the scheduler gobbles up
some limit number of new jobs, and starts them, and lets rest
wait for next interval. That limit being highish enough that
only under most unusual (high load) circumstances does it
matter at all.
When the scheduler then picks the job up, there goes some
time before the freshly started transport agent is up and
about, and announces itself being "#hungry" to accept a new
job -- your delivery. (System load depending, but presume
some message arrives which starts 50 parallel TA agents into
the worker-farm, there comes quite a load spike, but this
TA-agent - scheduler interaction interface does smooth it.)
At times I have been biffed with new email so fast that
I hardly have raised my finger from the enter key by which
I sent it.. But these delays being statistical animals,
they should be pretty much evenly distributed in between
zero, and router-interval plus scheduler-interval. About
that 30 seconds.
Also, in routers these delays are in play only when the system
is idle, so that ZMailer isn't churning your disks unnecessarily.
When you have lots of email, routers are in constant activity,
and scheduler takes lots of stuff to its workset every scan
interval. Unless routers have massive backlog, the through-
put delay goes down to average half of scheduler interval...
(Delivery delays are another story entirely, of course.)
> Reply also by email please (I'm not subscribed to the list). Notice also,
> that I'm a bit lame at SMTP :))
> Thanks in advance,
>
> ---
> Dani Pardo, dani@enpl.es
> Enplater S.A
/Matti Aarnio <matti.aarnio@sonera.fi>