Wietse Venema:
> 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.
Another possible test:
#ifconfig lo0 mtu 1500
That should decide any argument about write buffer sizes.
Wietse
