<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Other observations (before I head off doing other worldly things one has to do on Saturdays ;-):<div><br></div><div>- Changing `ZnUtils>>streamingBufferSize` from 16384 to 163840 (i.e. x10) also improves the performance (as expected) to 4s response time for the 55MB file</div><div>- In Pharo, the same code is used and there it takes 3s for the same file, same code (not quite the same Zinc version though, but the methods I mentioned are still the same)</div><div><br></div><div>Johan<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On 25 May 2024, at 08:57, Johan Brichau <johan@yesplan.be> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">The problem seems to be in `ZnUtils>>nextPutAll:on:` that splits the collection into chunks to write it to the Socket.<br>When I remove that method and just pass through the writing of the collection as `stream nextPutAll: collection`, I go from 39s to 1s (see below, before and after)<br><br>Now: understand why that piece of code is there and if it’s needed or not :-)<div><br>Johan<br><br><font face="Courier New">johanbrichau@JohansMacBookAir ~ % time curl http://localhost:8383/test --output bla.txt<br> % Total % Received % Xferd Average Speed Time Time Time Current<br> Dload Upload Total Spent Left Speed<br>100 55.2M 100 55.2M 0 0 1465k 0 0:00:38 0:00:38 --:--:-- 1476k<br>curl http://localhost:8383/test -output bla.txt 0.04s user 0.14s system 0% cpu 38.657 total</font><div><br></div><div><div><font face="Courier New"><br></font></div><div><div><font face="Courier New">johanbrichau@JohansMacBookAir ~ % time curl http://localhost:8383/test --output bla.txt</font></div><div><font face="Courier New"> % Total % Received % Xferd Average Speed Time Time Time Current</font></div><div><font face="Courier New"> Dload Upload Total Spent Left Speed</font></div><div><font face="Courier New">100 55.2M 100 55.2M 0 0 45.0M 0 0:00:01 0:00:01 --:--:-- 45.0M</font></div><div><font face="Courier New">curl http://localhost:8383/test --output bla.txt 0.01s user 0.07s system 6% cpu 1.255 total</font></div><br><br><blockquote type="cite">On 23 May 2024, at 23:45, Johan Brichau <johan@yesplan.be> wrote:<br><br class="Apple-interchange-newline">Hi Otto,<br><br><blockquote type="cite">On 20 May 2024, at 19:08, Otto Behrens <otto@finworks.biz> wrote:<br><br class="Apple-interchange-newline">Okay, I’ll give that a try and see what I can get when using the Zinc adaptor in GemStone…</blockquote><br><br>It took me a bit longer to actually get started since I wanted to debug this on my Mac using a GsDevKit_stones setup and I had to dig into another rabbit hole first :-)<br>Anyway, I setup the simple handler below and I can confirm also notice that a file of 60MB takes 40s to be served and 28MB takes 10s. <br><br>In Pharo, the 60MB file takes 3s.<br>I’ll dive into this a bit more tomorrow…..<br><br>get<br><br> <get><br> <path: '/'><br> <produces: 'application/json'><br><br> | file |<br> file := GsFile openReadOnServer: '/Users/johanbrichau/testfile'.<br> ^ file contents<br><br></blockquote><br></div></div></div></div></div></blockquote></div><br></div></body></html>