IPFS relies on the coordinated participation of a swarm of independent peers to function correctly. Therefore, measuring the performance and health of the network is crucial for ensuring its reliability and efficiency. In this context, we summarise a number of network characteristics as key performance indicators. Our KPIs are currently focusing primarily on the public IPFS DHT (although we do report on other parts of the architecture too). Understanding that IPFS is an ecosystem of content routing subsystems, over time, we plan to expand to other content routing subsystems too.

Network Size & Stability #

Client vs Server Node Estimate #

The total number of peers in the network is estimated using the number of unique Peer IDs seen by Protocol Labs’ bootstrap nodes. The number of unique DHT Server peer IDs identified by the Nebula crawler is then subtracted from the total number of peers (seen by the bootstrappers) to estimate the number of peers that exclusively function as DHT Clients.

Unique Software Agents #

The total number of unique software agents operating in the network is estimated from those seen by Protocol Labs’ bootstrap nodes when a peer connects. The number of unique agents seen by the Nebula crawler when crawling the IPFS DHT is included for comparison. The software agent strings have not been refined or processed, resulting in the count treating major and minor versions of each software agent as distinct entries.

Content Routing #

IPFS employs several content routing subsystems, with the Kademlia Distributed Hash Table (DHT) being the most established. Within the network, peers commonly use this system to locate other peers that hold the content being requested. We measure the availability of DHT server nodes and the latency of DHT lookups for random content.

DHT server availability #

We categorize DHT Server nodes with regard to their “availability” as follows:

  • “Online”: the node has been found online for 80% of time or more.
  • “Mostly Online”: the node has been found online between 40%-80% of time.
  • “Mostly Offline”: the node has been found online between 10%-40% of time.
  • “Offline”: the node has been found online less than 10% of time.

Data is collected using the Nebula crawler.

DHT Server Availability #

DHT Server Availability, classified over time #

DHT Lookup performance #

We use Parsec to capture the DHT Lookup performance over time and from several different geographic locations. In this section we present the average performance over all regions.

DHT Lookup Performance #

Historic DHT Lookup Performance #

The historic trend over time is currently provided by Parsec. Before 21 April 2023 an older script was used that queried IPFS preload servers to measure DHT lookup performance.

IPNI utilization #

IPNI is a set of protocols that describe how data can be indexed across the IPFS and Filecoin networks. Network indexers complement the IPFS DHT to enable peers to locate content-addressed data. The data in the plot below shows the number of requests made per day to the network indexers operated by cid.contact.

Websites #

A common use-case for IPFS is hosting websites, addressed using IPNS or DNSLink. We monitor the time it takes to load sample websites using the Tiros monitoring tool.

Time to First Byte for IPFS Hosted Websites #

HTTP Gateway Usage #

Gateway Requests #

The following plot shows the total number of requests made per day to the public IPFS gateways operated by Protocol Labs (ipfs.io and dweb.link). Data is collated from nginx access logs that front the gateway infrastructure.