Difference between revisions of "Internet Computer performance"
m |
Diego.prats (talk | contribs) m (Diego.prats moved page Internet Computer Performance to Internet Computer performance: change capitalization to way wikipedia does it) |
||
| (12 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | This post describes | + | This post describes the DFINITY Foundation's performance evaluation of the Internet Computer. The [https://forum.dfinity.org/t/internet-computer-performance-dec-1-2021-load-testing/9240 current measurements] are from November 2021. |
| − | Scalability of the Internet Computer comes from | + | Scalability of the Internet Computer comes from sharding the IC into subnet blockchains. Every subnet blockchain can process update calls (writes) from ingress messages independently from other subnets. The IC can scale up by adding more subnets at the cost of having more network traffic (as applications potentially need to communicate across subnets). In its current form, the IC should be able to scale out to hundreds of subnets. |
| − | + | Query calls (reads) can be processed locally by nodes in a subnet. The response to a query call can therefore have low latency since the query it just needs a response by a single node and does not need inter-node communication or agreement. The more nodes a subnet has, the more query calls it can handle; and the more nodes the IC has, the more query calls it can handle. | |
| − | + | == Test setup == | |
| − | |||
| − | |||
| + | The experiments were run concurrently against all subnets other than the NNS and some of the most utilized application subnets to avoid disturbance of active IC users. | ||
| + | The IC has a set of boundary nodes that route calls to the core nodes that host the subnets. The experiments sent loads against the subnets directly and are did not route traffic through the boundary nodes. Boundary nodes have additional rate limiting, which is currently set slightly more conservative compared to what the IC can handle and running against the boundary nodes would therefore be unsuitable for performance evaluation. | ||
| + | The experiment targeted all nodes in every subnet concurrently, much the same as what boundary nodes would be doing if we would use them. | ||
| + | The experiment consisted of installing one counter canister in every subnet. This counter canister is essentially a no-op canister. It only maintains a counter, which can be queried via query calls and incremented via update calls. The counter value is not using orthogonal persistence, so the overhead for the execution layer of the IC is minimal. Stressing the counter canister can be seen as a way to determine the system overhead or baseline performance. | ||
== Measurements == | == Measurements == | ||
=== Update calls === | === Update calls === | ||
| − | The Internet Computer can currently sustain more than | + | The Internet Computer can currently sustain more than '''11'000 updates/second''' for a period of four minutes, with peaks over '''11'500 updates/second.''' |
| + | |||
| + | The update calls we have been measuring here are triggered from ingress messages sent from outside the IC. | ||
[[File:update-call-performance.png|1024px|Update Call Performance]] | [[File:update-call-performance.png|1024px|Update Call Performance]] | ||
| Line 22: | Line 26: | ||
[[File:query-call-performance.png|1024px|Query Call Performance]] | [[File:query-call-performance.png|1024px|Query Call Performance]] | ||
| − | The Internet Computer can currently process up to | + | The Internet Computer can currently process up to '''250'000 queries per second.''' |
| − | + | During the experiment each load is increased incrementally and run for a period of 5 minutes. | |
| − | During | + | |
| + | == Conclusion and next steps == | ||
| + | |||
| + | The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC using: | ||
| + | |||
| + | * More subnets: This will immediate increase the query and update call throughput. While adding subnets might eventually lead to other scalability problems, the IC in its current shape should be able to support hundreds of subnets. | ||
| + | * Performance improvements: Performance can also be improved by better single machine, network and consensus performance tuning. Increasing the performance by at least an order of magnitude is plausible. | ||
Latest revision as of 20:50, 18 January 2022
This post describes the DFINITY Foundation's performance evaluation of the Internet Computer. The current measurements are from November 2021.
Scalability of the Internet Computer comes from sharding the IC into subnet blockchains. Every subnet blockchain can process update calls (writes) from ingress messages independently from other subnets. The IC can scale up by adding more subnets at the cost of having more network traffic (as applications potentially need to communicate across subnets). In its current form, the IC should be able to scale out to hundreds of subnets.
Query calls (reads) can be processed locally by nodes in a subnet. The response to a query call can therefore have low latency since the query it just needs a response by a single node and does not need inter-node communication or agreement. The more nodes a subnet has, the more query calls it can handle; and the more nodes the IC has, the more query calls it can handle.
Test setup
The experiments were run concurrently against all subnets other than the NNS and some of the most utilized application subnets to avoid disturbance of active IC users. The IC has a set of boundary nodes that route calls to the core nodes that host the subnets. The experiments sent loads against the subnets directly and are did not route traffic through the boundary nodes. Boundary nodes have additional rate limiting, which is currently set slightly more conservative compared to what the IC can handle and running against the boundary nodes would therefore be unsuitable for performance evaluation. The experiment targeted all nodes in every subnet concurrently, much the same as what boundary nodes would be doing if we would use them.
The experiment consisted of installing one counter canister in every subnet. This counter canister is essentially a no-op canister. It only maintains a counter, which can be queried via query calls and incremented via update calls. The counter value is not using orthogonal persistence, so the overhead for the execution layer of the IC is minimal. Stressing the counter canister can be seen as a way to determine the system overhead or baseline performance.
Measurements
Update calls
The Internet Computer can currently sustain more than 11'000 updates/second for a period of four minutes, with peaks over 11'500 updates/second.
The update calls we have been measuring here are triggered from ingress messages sent from outside the IC.
Query calls
Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.
The Internet Computer can currently process up to 250'000 queries per second. During the experiment each load is increased incrementally and run for a period of 5 minutes.
Conclusion and next steps
The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC using:
- More subnets: This will immediate increase the query and update call throughput. While adding subnets might eventually lead to other scalability problems, the IC in its current shape should be able to support hundreds of subnets.
- Performance improvements: Performance can also be improved by better single machine, network and consensus performance tuning. Increasing the performance by at least an order of magnitude is plausible.