Hi, <br><br>Brian, thank you for your detailed reply.<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'd suggest a test framework which uses multiple simultaneous "tahoe<br>
put" commands, each in a separate process (ideally on a different<br>
machine than the Tahoe node, to factor out contention for CPU and local<br>
disk between your test harness and the Tahoe node).<br></blockquote><div><br>You found in attachement a script that sends multiple files simultaneously. I done those tests on my laptop (test1 -> test3) and on the tahoe test platform (test4). The results are better than uploading sequentially small files but when files are larger this adds an overhead to each upload at least ~2s (1MB files). <br>
<br>Parallelism is easy to add in my application :) but adding my code into the tahoe node is not obvious (I need to convert my code java -> python)<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
The quickest way to measure the HTTP roundtrip latency is to do "time<br>
echo -n '' |tahoe put". That uploads a zero-byte file, which Tahoe does<br>
by creating a "URI:LIT" filecap, which is not distributed and doesn't<br>
even talk to the storage servers. Then compare the time it takes to do<br>
that against uploading a 100-byte file, which *is* distributed and does<br>
the usual tahoe upload work. On my laptop, the zero-byte file takes<br>
971ms to upload, <br></blockquote><div><br>This is strange! <br><br>Regards,<br>Wassim<br><br><br></div></div>