<div dir="auto">Hi Mikael</div><div dir="auto"><br></div><div dir="auto">Thanks for pointing out prim_inet. To my knowledge, it’s undocumented I can be changed by the OTP team. That’s why I’ve avoided it at the first place. </div><div dir="auto"><br></div><div dir="auto">By the way, you probably mean prim_inet:sendfile/4 not 8, correct?</div><div dir="auto"><br></div><div dir="auto">I made a quick the change to my app and found that the throughput is a little bit better (3% faster).</div><div dir="auto"><br></div><div dir="auto">But these port locks are still there :-/</div><div dir="auto">Any other ideas?</div><div dir="auto"><br></div><div dir="auto">/Frank</div><div dir="auto"><br></div><div>On Thu, Jan 2, 2020 at 5:38 PM Frank Muller <<a href="mailto:frank.muller.erl@gmail.com" target="_blank">frank.muller.erl@gmail.com</a>> wrote:<br></div><div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> Thanks to @Peti Gömöri, I was able to identify these Port locks:<br>
> <a href="https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5" rel="noreferrer" target="_blank">https://gist.github.com/frankmullerl/008174c6594ca27584ac7f4e6724bee5</a><br>
><br>
> Some of them are taking up to 6.7sec (6707846 usec) :-/<br>
><br>
> My application is serving static images by calling file:sendfile/2 (<a href="https://erlang.org/doc/man/file.html#sendfile-2" rel="noreferrer" target="_blank">https://erlang.org/doc/man/file.html#sendfile-2</a>).<br>
><br>
> Can someone please explain how I can avoid these locks or at least make their impact lesser?<br>
<br>
Using the file module has been known to cause synchronization<br>
overheads.  Often we (Klarna) use prim_file instead,<br>
but it has sendfile/8 not /2.  Anyway, that may be an avenue worth<br>
investigating.<br>
</blockquote></div></div>