[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-19 13:14:41
Message-ID: d2f867db-4910-447c-f83c-aa4416177af7 () rmail ! de
[Download RAW message or body]

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

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