#3952 closed enhancement (fixed)

Benchmarks for basic immutable Tahoe operations (upload and download)

Reported by: itamarst Owned by:
Priority: normal Milestone: HTTP Storage Protocol
Component: unknown Version: n/a
Keywords: Cc:
Launchpad Bug:

Description

Motivation:

  1. We don't want HTTP to be slower than Foolscap.
  2. It's not clear how fast these operations are in general.

Thus: there should be a way to measure how long these operations take.

First pass will run over loopback, but latency can be added-on on Linux (e.g. https://bencane.com/2012/07/16/tc-adding-simulated-network-latency-to-your-linux-server/).

Change History (6)

comment:1 Changed at 2022-12-12T16:26:00Z by itamarst

  • Summary changed from Benchmarks for basic immutable Tahoe operations to Benchmarks for basic immutable Tahoe operations (upload and download)

comment:2 Changed at 2022-12-12T20:01:04Z by itamarst

For a small 2000 byte file with a single share uploaded to a single node, an upload is 3 sequential HTTP requests, and a download is 4 sequential HTTP requests. So with high latency this gets quite slow.

Next, 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.

  • When uploading the 2000 byte file, upload time was 300ms (30ms CPU), and download was 300ms (65ms CPU).
  • When uploading a 2MB file, upload time was 700ms (70ms are CPU), and download time was 3200ms (680ms is CPU).
  • For 20MB file: upload 3,550ms (CPU 600ms), download 31,200ms (6,200ms CPU).

This is all sharing a single CPU core for both client and server, it's one big process.

So at first glance:

  • 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.
  • 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.
Version 1, edited at 2022-12-12T20:11:56Z by itamarst (previous) (next) (diff)

comment:3 Changed at 2022-12-13T18:19:57Z by itamarst

Last edited at 2022-12-14T15:48:51Z by itamarst (previous) (diff)

comment:4 Changed at 2022-12-13T18:42:49Z by itamarst

Changing default segment size to be bigger helps a lot (mostly a workaround).

comment:5 Changed at 2023-01-23T16:51:42Z by itamarst

The problems with increasing default segment size:

comment:6 Changed at 2023-02-23T15:30:54Z by itamarst

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.