[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postfix-users
Subject:    Re: postfix milter body chunk length
From:       Matthias Schneider <matthias.schneider () rmail ! de>
Date:       2019-08-20 15:06:59
Message-ID: 674ee1ca-d54a-46b9-d146-79c1f227dfc7 () rmail ! de
[Download RAW message or body]

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
[prev in list] [next in list] [prev in thread] [next in thread]