Hi Wietse,
I suspect that the bottleneck is on the receiving side.
- Maybe the loopback stack does not like the 65535 block size. Try
using an ethernet interface address instead.
I tried switching from interface lo to eno1 - same issue.
- Maybe the application "appends" the new content to the end of a
large string; that requires allocating and copying huge amounts of
memory each time. That alone may explain the difference in program
speed.
I just append to a bytes buffer, its very fast on unix socket (same
code), its also fast when i use a own milterclient implementation in golang.
- Maybe the above program behavior triggers a worst case in the
malloc library as it needs to deal with copies of strings of
increasing length.
You can test that with a test program that does nothing with the
data, such as the test-milter program that is part of Postfix
source code.
Wietse
I compared some tcpdumps with postfix as client and my milterclient
(which is fast) as client.
It seems that we run into nagle timeout (the ACK is always delayed).
Setting TCP_QUICKACK on my milter socket doesnt help, is there a way to
set TCP_NODELAY on the milter connection in postfix?
Matthias Schneider
