Changes between Initial Version and Version 1 of Ticket #3952, comment 2


Ignore:
Timestamp:
2022-12-12T20:11:56Z (2 years ago)
Author:
itamarst
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #3952, comment 2

    initial v1  
    33Next, I tested over loopback, but with RTT latency of 60ms (30ms one way) artificially added. Bandwidth is quite high, so not likely to be a bottleneck.
    44
    5 * When uploading the 2000 byte file, upload time was 300ms, and download was 300ms.
    6 * When uploading a 2MB file, upload time was 300ms, and download time was 3200ms.
     5* When uploading the 2000 byte file, upload time was 300ms (30ms CPU), and download was 300ms (65ms CPU).
     6* When uploading a 2MB file, upload time was 700ms (70ms are CPU), and download time was 3200ms (680ms is CPU).
     7* For 20MB file: upload 3,550ms (CPU 600ms), download 31,200ms (6,200ms CPU).
    78
    8 Thus:
     9This is all sharing a single CPU core for both client and server, it's one big process.
    910
    10 * Immutable uploads use parallelism, and main bottleneck is latency, which only impacts small files. However, sequential uploads will have minimal time no matter what the bandwidth.
    11 * Immutable downloads have a latency hit, but even worse are not utilizing parallelism well, so large files suffer from latency hit even when bandwidth is not a bottleneck.
     11So at first glance:
     12
     13* Immutable uploads use parallelism, and main bottleneck is latency. Upload time is not linear with size, . However, sequential uploads will have minimal time no matter what the bandwidth.
     14* Immutable downloads have a massive latency hit, probably due to not utilizing parallelism well, so large files suffer from latency hit even when bandwidth is not a bottleneck. Also using a lot of CPU.