Kubo

IPFS Kubo End-to-End Performance

This chart breaks down the End-to-End performance of Kubo vNone by showing the full content routing lifecycle split in the Upload and Download phases. Each phase is broken up into its constituent steps. The chart shows aggregate numbers of 24h of repeated measurements. The graph subtitle shows when the 24h time window has ended.

Here, Upload is defined as adding a 100MiB blob of random bytes to a local Kubo node, and waiting for Kubo to store the provider record for the file's root CID in the Public Amino DHT.

A Download is defined as requesting a random CID that we have learned about with our Bitswap sniffer tool from the network using the different content routing systems DHT and IPNI (and also Bitswap which is technically not a content routing system).

These are the different steps for the Upload phase:

• Add Duration: The time it took to merkle-ize the 100MiB file and add it to the Kubo node. We use the default Kubo configuration (which has the default datastore's sync property set to false) except for the Provide.Strategy which we have set to root, so that we can guarantee deterministic behavior with regards to when CIDs are provided to the DHT. The measurement setup expects this to happen shortly after we have added the file to the Kubo node.

• Provide Delay: The delay from when the file was added to the Kubo node until the provide operation was started.

• Provide Duration: The time from when the provide operation started until the provider records were written to the DHT.

These are the different steps for the Upload phase:

• Time to broadcast: The time it took until the DHT and IPNI content routing subsystems were activated to resolve the CID's providers. Kubo implements a "Provider Search Delay" of 1s in which it asks its immediately connected peers via Bitswap if they happen to have the content for the CID. Kubo waits up to 1s for a positive response before it broadcasts the request to the DHT or IPNI. This "Time to broadcast" bar should almost always be around 1s. If our Kubo deployment is clogged, the delay could be longer for higher percentiles.

• Provider found delay: The time it took until the provider was found via the DHT or IPNI relative to the time when the broadcast operation started.

• Provider connection delay: The time it took until our Kubo node has established a connection to the provider relative to the time when the provider was found.

• TTFB delay: The time it took until the first byte of the file was received from the provider relative to the time when the provider connection was established.

The number of samples that comprise this measurement is shown in the tooltip when hovering over the lines.

IPFS Kubo Upload Performance

This chart shows the average upload performance of the IPFS Kubo node from several different regions. Here, Upload is defined as adding a 100MiB blob of random bytes to a local Kubo node, and waiting for Kubo to store the provider record for the file's root CID in the Public Amino DHT. The overall latency in seconds is shown on the left y-axis and is broken down to the several stages of the process:

• Add Duration: The time it took to merkle-ize the 100MiB file and add it to the Kubo node. We use the default Kubo configuration (which has the default datastore's sync property set to false) except for the Provide.Strategy which we have set to root, so that we can guarantee deterministic behavior with regards to when CIDs are provided to the DHT. The measurement setup expects this to happen shortly after we have added the file to the Kubo node.

• Provide Delay: The delay from when the file was added to the Kubo node until the provide operation was started.

• Provide Duration: The time from when the provide operation started until the provider records were written to the DHT.

We are showing average latencies here as opposed to percentiles because they are additive and only this allows us to correctly visualize the different steps as stacked bars. The tooltip shows more information like the total P50 and P90 percentile latencies, plus the number of samples used to calculate the aggregations.

The resource provisioning of our Kubo node under test is as follows:

• 1vCPU
• 2GB RAM

The right y-axis shows the number of samples used to produce each daily aggregation.

IPFS Kubo Download Performance

This chart shows the average download latency in seconds of the IPFS Kubo node from several different regions. The first dropdown menu allows filtering by the different regions and the second by the content routing methods.

A Download is defined as requesting a random CID that we have learned about with our Bitswap sniffer tool from the network using the different content routing systems DHT and IPNI (and also Bitswap which is technically not a content routing system). The Download measurements show the latencies until we have received the first byte. This decouples the Download measurement numbers from the file size of the random CID.

We are showing average latencies here as opposed to percentiles because they are additive and only this allows us to correctly visualize the different steps as stacked bars. The tooltip shows more information like the total P50 and P90 percentile latencies, plus the number of samples used to calculate the aggregations.

In our measurement setup we effectively run the command ipfs cat $CID until we have downloaded at most 10MiB of data. This limit was chosen to not generate unnecessary network load.

The download performance is broken down to each stage of the process:

• Time to broadcast: The time it took until the DHT and IPNI content routing subsystems were activated to resolve the CID's providers. Kubo implements a "Provider Search Delay" of 1s in which it asks its immediately connected peers via Bitswap if they happen to have the content for the CID. Kubo waits up to 1s for a positive response before it broadcasts the request to the DHT or IPNI. This "Time to broadcast" bar should almost always be around 1s.

• Provider found delay: The time it took until the provider was found via the DHT or IPNI relative to the time when the broadcast operation started.

• Provider connection delay: The time it took until our Kubo node has established a connection to the provider relative to the time when the provider was found.

• TTFB delay: The time it took until the first byte of the file was received from the provider relative to the time when the provider connection was established.

The samples used to produce the graph is shown on the right y-axis.

The resource provisioning of our Kubo node under test is as follows:

• 1vCPU
• 2GB RAM