Matthias Schneider:
> I have tested your patch, it's working fine. The speed is like unix socket!
> Any chance it will go into next release?

Thank you for trying the patch.

This could be a performance fix for all stable releases. It addresses
the problem at the most basic level: Postfix tries to use the network
stack efficiently by not doing "small" writes back-to-back. I don't
want to set TCP_NODELAY because that would hide bugs in Postfix design.

        Wietse

> Am 20.08.19 um 15:47 schrieb Wietse Venema:
> > Matthias Schneider:
> >> Once i do "ip link set dev lo mtu 21845" i will get vstream_tweak_tcp:
> >> TCP_MAXSEG 21793 and the performance is great (only 1 second for 100mb
> >> body).
> > In both cases, Postfix was sending 65535-byte body chunks?
> >
> > Then the problem was that getsockopt(TCP_MAXSEG) returned a too
> > small MSS value. As implemented, vstream_tweak() will use 2x the
> > the TCP_MAXSEG result for its I/O buffer size, to allow for dynamic
> > changes in network routing. In your case, the 2x multiplier was not
> > sufficient.
> >
> > If you have source, can you try the patch below:
> >
> > --- ./src/util/vstream_tweak.c-     2014-12-25 11:47:17.000000000 -0500
> > +++ ./src/util/vstream_tweak.c      2019-08-20 09:45:52.000000000 -0400
> > @@ -132,6 +132,8 @@
> >       if (mss > EFF_BUFFER_SIZE(fp) / 2) {
> >     if (mss < INT_MAX / 2)
> >         mss *= 2;
> > +   if (mss < INT_MAX / 2)
> > +       mss *= 2;
> >     vstream_control(fp,
> >                     CA_VSTREAM_CTL_BUFSIZE(mss),
> >                     CA_VSTREAM_CTL_END);
> >
> > Yes, this duplicates two lines of code.
> >
> >     Wietse
> 

Reply via email to