IPFS KPIs #

Please note that this website is a preview and is subject to change at any time. We strive to provide accurate and up-to-date information, but we cannot guarantee the completeness or reliability of the information presented during the preview.

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.

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.

DHT Server Availability #

DHT Server Availability, classified over time #

DHT Lookup performance #

We have instrumented the following experiment to capture the DHT Lookup performance over time and from several different geographic locations. We have set up IPFS DHT Server nodes in seven (7) different geographic locations. Each node periodically publishes a unique Content Identifier (CID) and makes it known to the rest of the nodes, who subsequently request it through the DHT (acting as clients). This way we capture the DHT Lookup performance from each location. In this section we present the average performance over all regions.

DHT Lookup Performance #

Historic 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 and Traffic #

A common use-case for IPFS is hosting websites, addressed using IPNS or DNSLink. We monitor the time it takes to load sample websites through a browser and the number of requests to the public Protocol Labs operated IPFS gateways.

Time to First Byte for IPFS Hosted Websites #

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).