Rocco Scappatura:
> Thanks Wietse and Victor,
>
> >> >> For example consider the log relative to the relay entries (to the
> >> >> cntent
> >> >> filer and to postfix without conten filter):
> >> >>
> >> >> 1) Jan 30 10:02:17 av5 postfix/smtp[10603]: C0AFB226F23:
> >> >> to=<recei...@domain.tld>, relay=127.0.0.1[127.0.0.1]:10026,
> >> delay=8.9,
> >> >> delays=1.3/0/0/7.7, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
> >> >> 95CEE226F30)
> >> >
> >> > Postfix measures 7.7 seconds from start of delivery to end of
> >> delivery.
> >>
> >> You are saying the time the SMTP connection with 127.0.0.1:10026 to the
> >> time that the same connection is ended? And this interval includes the
> >> processing too?
> >
> > There are 7.7 seconds between the time that the Postfix SMTP client
> > sends the MAIL FROM command to the filter, and the time that the
> > filter sends the end-of-data reply to the Postfix SMTP client.
> >
> >> > Either the content filter has a very slow SMTP implementation, or
> >> > the content filter spends a lot of time to inspect the message.
> >> > You can easily verify which it is, by looking with top or some
> >> > other performance measurement tool.
> >
> > You can find out how much of the 7.7 seconds is spent on CPU time,
> > and how much of that time is spent waiting for DNS, disk I/O, or
> > something else. I won't do that for you, for obvious reasons.
> >
> >> 2) Jan 30 10:02:17 av5 postfix/smtp[5441]: 95CEE226F30:
> >> to=<recei...@domain.tld>, relay=server[xxx.yyy.zzz.uuu]:25, delay=0.11,
> >> delays=0.03/0.04/0.01/0.03, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued
> >> as 5C7951098002)
> >
> > There are 0.3 seconds between the time that the Postfix SMTP client
> > sends the MAIL FROM command to xxx.yyy.zzz.uuu, and the time that
> > xxx.yyy.zzz.uuu sends the end-of-data reply to the Postfix SMTP
> > client.
>
> So.. raising "maxprocs" value for the contet filter could not reduce delay
> "d" in 1) anyway.. Right? To raise "maxprocs" value for the contet filter
> helps only when is the active queue congested.. I think..
That depends on how much of that time the filter is busy in the
CPU, and how much it spends waiting for DNS or disk I/O.
If the filter spends 100% of its time busy in the CPU, then the
optimal number of filter processes is a few times the number of
CPUs. If the filter spends 50% of its time in the CPU, then the
optimal number of filter processes is twice as large.
> Could you explain - in the same terms - how is quantified the time before
> a message is passed to the queue manager, after it is processed by the
> content filter?
The time to deliver is measured as the time between MAIL FROM and
"end-of-data".
Wietse
