>> >> >> 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.
Very interesting! I will observe closely this a spect.. Thanks. >> 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". Sorry for my bad english.. To be clearer, given "delays=a/b/c/d" I asked for the meaning of "a" delay. I need this definition to understand better the difference of time between "d" in 1) and "d" in 2) in the example above. rocsca