Dave Green:
> > Can you do some tests with a recent version of Postfix's own stress
> > testing tool?
>
> smtp-source -t bitbuc...@sigmasys.co.uk -l 5242880 -m 10 206.125.173.103
> 0m42.62s real 0m0.02s user 0m0.31s system
>
> smtp-source -t bitbuc...@sigmasys.co.uk -l 5242880 -m 10 127.0.0.1
> 0m8.27s real 0m0.03s user 0m0.23s system
>
> 1.17Mbytes/s for the physical interface vs. 6.0MBytes/s for loopback.
> clamav-milter scans mail from the external interface but not from
> localhost and probably accounts for the difference here.
>
> The latter numbers (127.0.0.1 @6.0MBytes/s) are *considerably* better than
> those occurring with the test attachment I was using
> (http://sigmasys.co.uk/postfix/test.bin), where a 2Mb attachment via SMTP
> takes well over a minute to be processed. I'm not sure why this might be,
> or why I obtain results more comparable to 6.0MBytes/s when mail arrives
> via pickup. As far as I can tell cleanup goes through the same process
> each time independent of how mail is presented to it.
My conclusion is that the delay happens *before* the Postfix SMTP
server. There is nothing magic about the way that smtp-source works,
apart from making sure that its write buffer is larger than the
MTU of the network interface (whether loopback or physical) so that
it isn't hurt by Nagle delays.
I suspect that the mail sending app is using the loopback interface
in a sub-optimal manner, perhaps Nagle, perhaps something else.
Time to pull out good old "tcpdump -i lo0 -w /file/name port 25"
and capture a recording. You don't need to capture the packet
payload to find out where the delays are happening.
I'll continue this thread tomorrow.
Wietse
