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
