<div dir="auto">Correct. But if you control how many connections you are reading, then you control how much memory you spend on that. Hence reading 100 connections 10kb at a time won't pin more than 1mb. But if you don't have control over how many connections you are reading from, which is the case with sync API, then you might be pinning 100mb before one request becomes available.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 24 Jul 2022, 16:52 Pedro Lamarão, <<a href="mailto:pedro.lamarao@prodist.com.br">pedro.lamarao@prodist.com.br</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">Em dom., 24 de jul. de 2022 às 10:08, Alex Otenko <<a href="mailto:oleksandr.otenko@gmail.com" target="_blank" rel="noreferrer">oleksandr.otenko@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">Also, I am not clear why you dismissed the allocation problem by just saying IO buffering is the same. The allocation problem is that user code allocates before read(byte[]) is called. This is the same in both sync and async code. The difference is that in async code the lifespan of the allocation is shorter - we read only read-ready channels, and those that aren't ready return quickly. In sync code the buffer remains allocated for a long time - even seconds, if that's what the connection reuse pattern is on the client side.</div></div></blockquote></div><div><br></div><div>I am not what this allocation problem is supposed to be.</div><div>If you have provisioned the memory required to support your workload,</div><div>it doesn't matter for how long some buffer remains "inside" a call.</div><div>If you have not provisioned the memory required to support your workload,</div><div>then you have an architectural problem no matter how little time some buffer remains "inside" a call;</div><div>you will crash when concurrent reads peak.</div><div>Am I missing something?</div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>
</blockquote></div>