postfix milter body chunk length

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: postfix milter body chunk length

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 | Threaded
Open this post in threaded view
|

Re: postfix milter body chunk length

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?

Matthias Schneider




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 | Threaded
Open this post in threaded view
|

Re: postfix milter body chunk length

Wietse Venema
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 | Threaded
Open this post in threaded view
|

Re: postfix milter body chunk length

Matthias Schneider
Thanks Wietse for your help.

before patch:
16:50:57.609 Recv body (104 MB): 0:01:07.126

after patch:
16:52:16.248 Recv body (104 MB): 0:00:00.361


Matthias Schneider


Am 20.08.19 um 16:27 schrieb Wietse Venema:

> 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 | Threaded
Open this post in threaded view
|

Re: postfix milter body chunk length

Chris Wedgwood
In reply to this post by Matthias Schneider
i did a quick test using tcp, i see significant no difference in
performance vs using a unix domain socket
12