You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This test plan measures a series of transfers between two nodes with graphsync, optionally comparing them to HTTP. It offers a wide variety of configurable parameters, which are documented here.
6
+
7
+
### File Parameters
8
+
9
+
These parameters configure the nature of the file that is transfered:
10
+
11
+
-`size` - size of file to transfer, in human-friendly form
12
+
-**Default**: 1MiB
13
+
-`chunk_size` - unixfs chunk size (power of 2), controls the size of the leaves in file
14
+
-**Default**: 20 *(or 1MB chunks)*
15
+
-`links_per_level` - unixfs links per level, controlles UnixFS DAG shape (wide vs deep)
16
+
-**Default**: 1024
17
+
-`raw_leaves` - should unixfs leaves be raw bytes (true), or wrapped as protonodes (false)
18
+
-**Default**: true
19
+
-`disk_store` - when we ingest the file to unix fs, should the blockstore where it lives be stored on disk (true) or memory (false)
20
+
-**Default**: default - false
21
+
-`concurrency` - number of files to construct and attempt to transfer *simultaneously*
22
+
-**Default**: 1
23
+
24
+
Why you might want to change these:
25
+
- obviously large file sizes more closely mirror use cases in a typical filecoin data transfer work load
26
+
- the links per level, chunk size, and raw leaves allow you to expriment with different dag structures and see how graphsync performs in different conditions
27
+
- the disk store allows you to measure the impact of datastore performance
28
+
- concurrency allows you to test how graphsync performs under heavy loads of attempting transfer many files simultaneously
29
+
30
+
### Networking Parameters
31
+
32
+
These parameters control the parameters for the network layer
33
+
-`secure_channel` - type secure encoding for the libp2p channel
34
+
-**Default**: "noise"
35
+
-`latencies` - list of non-zero latencies to run the test under.
36
+
-**Default**: 100ms, 200ms, 300ms
37
+
-`no_latency_case` - also run a test case with no latency
38
+
-**Default**: true
39
+
-`bandwidths` - list limited bandwidths (egress bytes/s) to run the test under (written as humanized sizes).
40
+
-**Default**: 10M, 1M, 512kb
41
+
-`unlimited_bandwidth_case` - also run a test case with unlimited latency
42
+
-**Default**: true
43
+
44
+
Why you might want to change these:
45
+
- we may pay a penalty for the cost of transfering over secure io
46
+
- bandwidth and latency parameters allow you to test graphsync under different network conditions. Importantly, these parameters generate a new test case for each instance, in a combinatorial form. So, if you you do two latencies and two bandwidths, you will get 4 rounds. And if concurrency is >1, each round with have more than one transfer
47
+
48
+
### Graphsync Options
49
+
50
+
The parameters control values passed constructing graphsync that may affect overall performance. Their default values are the same default values is no value is passed to the graphsync constructor
51
+
52
+
-`max_memory_per_peer` - the maximum amount of data a responder can buffer in memory for a single peer while it waits for it to be sent out over the wire
53
+
-**Default**: 16MB
54
+
-`max_memory_total` - the maximum amount of data a responder can buffer in memory for *all peers* while it waits for it to be sent out over the wire
55
+
-**Default**: 256MB
56
+
-`max_in_progress_requests` - The maximum number of requests Graphsync will respond to at once. When graphsync receives more than this number of simultaneous in bound requests, those after the first six (with a priotization that distributes evenly among peers) will wait for other requests to finish before they beginnin responding.
57
+
-**Default**: 6
58
+
59
+
These performance configuration parameters in GraphSync may cause bottlenecks with their default values. For example if the `concurrency` parameter is greater than 6, the remaining files will block until graphsync finishes some of the first 6. The buffering parameters may artificially lower performance on a fast connection. In a production context, they can be adjusted upwards based on the resources and goals of the graphsync node operator
60
+
61
+
### HTTP Comparison Parameters
62
+
63
+
The parameters allow you to compare graphsync performance against transfer of the same data under similar conditions over HTTP
64
+
65
+
-`compare_http` - run the HTTP comparison test
66
+
-**Default**: true
67
+
-`use_libp2p_http` - if we run the HTTP comparison test, should we use HTTP over libp2p (true) or just use standard HTTP on top of normal TCP/IP (false)
68
+
-**Default**: false
69
+
70
+
### Diagnostic Parameters
71
+
72
+
These parameters control what kind of additional diagnostic data the test will generate
73
+
74
+
-`memory_snapshots` - specifies whether we should take memory snapshots as we run. Has three potention values: *none* (no snapshots), *simple* (take snapshots at the end of each request) and *detailed* (take snap shots every 10 blocks when requests are executing). Note: snapshoting will take a snapshot, then run GC, then take a snapshot again. *detailed* should not be used in any scenario where you are measuring timings
75
+
-**Default**: none
76
+
-`block_diagnostics` - should we output detailed timings for block operations - blocks queued on the responder, blocks sent out on the network from the responder, responses received on the requestor, and blocks processed on the requestor
0 commit comments