Martin Kellermann put forth on 12/2/2010 6:08 AM:
> relay=IP[IP]:PORT, delay=5.7, delays=0.6/0/0.03/5.1, dsn=5.1.1,
> --------------
> and there's a 5 sec. delay ... seems way too long to me for just
> checking the recipient...!?
Completion of support for time stamps from different stages
of message delivery. The information is now logged as
"delays=a/b/c/d" where a=time before active queue, b=time
in active queue, c=connection setup time, d=actual message
delivery.
Note that the bulk of your delay was during the "message delivery"
phase. AFAIK verify(8) actions (RCPT TO) are included in this phase.
If that was the very first RAV probe you'd obviously have some startup
time delay, as the database file would be created for the first time,
along with making the actual probe to the Exch server. Monitor these
delays for a few days after you have RAV in production, and if those "d"
delays are still high let us know.
Also, if you are intending to test RAV performance before going into
production, you need to perform at least one RAV query every 100s or the
verify daemon will exit due to $max_idle = 100s. Once the daemon exits,
the next RAV will suffer startup time, giving you unrealistic delay
results compared to being in production. The startup time should
typically be less than 1 second, but all the little delays add up.
Eliminating all of these on the Postfix side will help narrow down
delays being introduced on the Exch side.
--
Stan
