https://wiki.internetcomputer.org/w/api.php?action=feedcontributions&feedformat=atom&user=Skaestle 2026-04-09T10:22:42Z User contributions MediaWiki 1.39.17 https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=6758 2023-11-22T10:47:13Z

<p>Skaestle: Most recent performance numbers as measured on CD.</p> <hr /> <div>'''While having the security of Web3 blockchains, the performance of the Internet Computer (IC) is comparable to Web2 and cloud technology stacks. The IC far outperforms traditional blockchain protocols in efficiency.'''<br /> <br /> == Performance goals==<br /> A key objective of the Internet Computer is to provide a public compute layer that replaces traditional IT. A natural concern is that this will cause far less efficient computation.<br /> <br /> The Internet Computer works very differently to other blockchains, and is powered by advanced new cryptography. Internally, the network is able to strictly limit the replication of data and computation, while still providing the liveness and security guarantees expected of a blockchain. It also has the ability to assign different “trust levels” to units of blockchain code that it hosts (“smart contracts”), which changes the level of replication applied to their computations and data. In its current state of development, it is already orders of magnitude more efficient than other blockchains, but it is designed to eventually become more efficient that traditional IT too.<br /> <br /> Like all blockchains, the Internet Computer network directly applies replication, in combination with advanced cryptography, to create a tamperproof platform with better liveness guarantees than traditional IT. Yet, it also limits replication, while using the replication that occurs to drive efficiency, for example by scaling out “query” transactions.<br /> <br /> For example, a large online service might be built on Amazon Web Services using a database in a master-slave configuration, Kubernetes instances of web workers, memcached instances for caching the results of database queries, and a CDN (content distribution network) that caches web content they serve on the edge of the network. This already creates a large amount of replication without creating a tamperproof platform, nor providing liveness guarantees. For example, each slave node of the database replicates its computations and data, and regular snapshots will also be taken as backups, data used by the web workers is replicated by the memcached instances, and each work will also cache data in its memory, while the product of web queries will be replicated all over the world on CDN nodes.<br /> <br /> Because replication is at the core of the design of the Internet Computer, it can derive powerful security, liveness and other properties from replication, while also applying it more efficiently. For example, because the Internet Computer is a single logical blockchain and platform, as it grows larger, the utilization of the underlying node hardware upon which it runs can be made higher than, say, a standalone server machine in a data center. A key objective of the Internet Computer is, over time, to provide a public compute platform that provides a more power efficient way for the world to build systems and services.<br /> <br /> == Performance experiments == <br /> Scalability of the Internet Computer is facilitated by 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.<br /> <br /> '''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 just needs a response by a single node and does not require 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.<br /> <br /> == Test setup ==<br /> <br /> 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. <br /> 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. <br /> The experiment targeted all nodes in every subnet concurrently, much the same as what boundary nodes would be doing if they would be used.<br /> <br /> 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.<br /> <br /> == Measurements ==<br /> <br /> We evaluate the performance of the IC on a CD pipeline, which is running periodically. Those benchmarks target a single subnetwork with a configuration close to IC nodes on mainnet. We scale up those numbers to the current number of nodes and subnetworks on mainnet, which yields the following numbers:<br /> <br /> Query calls: '''3,196,225''' queries/s (7,025 queries/s per node scaled up to 455 nodes in application subnetworks)<br /> <br /> Update calls: '''33,749''' updates/s (1,023 updates/s per subnetwork scaled up to 33 application subnetworks)<br /> <br /> Above calculation is based on measurements from: '''2023-11-22'''.<br /> <br /> All benchmark run against a small number of canister that simply return, as the goal of this benchmark is to measure throughput of the messaging subsystem and to determine runtime overhead of message processing.<br /> <br /> Canister code can be (almost) arbitrarily complex and therefor significantly lower the throughput if canister execution is becoming the bottleneck (and not messaging).<br /> <br /> ===Previous measurements ===<br /> The following measurements were made on '''May 24, 2022''', with 31 application subnets (having each 13 nodes) out of a total of 35 subnets (4 are system subnets such as the NNS and SNS subnets that have more nodes). Benchmarks where executed by simultaneously stressing all subnetworks on mainnet.<br /> <br /> ====Update calls====<br /> The Internet Computer sustained more than '''20'841 updates/second''' calls to application canisters for a period of four minutes (averaging '''672 updates/second''' per subnet).<br /> The update calls measured here are triggered from ingress messages sent from outside the IC.<br /> <br /> ====Query calls====<br /> Arguably more important are query calls, since they contribute to more than 90% of the traffic observed on the IC.<br /> The Internet Computer processed '''1'125'982 queries per second''' calls to application canisters (averaging '''2'792 queries per second''' per node).<br /> During the experiment each load is increased incrementally and run for a period of 5 minutes.<br /> <br /> <br /> ==Conclusion and next steps==<br /> The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC using:<br /> *More subnets: This will immediately 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.<br /> *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.<br /> <br /> ==See Also==<br /> *'''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''<br /> *[https://medium.com/dfinity/the-internet-computers-transaction-speed-and-finality-outpace-other-l1-blockchains-8e7d25e4b2ef The Internet Computer’s Transaction Speed and Finality Outpace Other L1 Blockchains]<br /> *[https://forum.dfinity.org/t/internet-computer-performance-dec-1-2021-load-testing/9240 Internet Computer Performance - Dec 1, 2021 Load testing]<br /> ===References=== <br /> &lt;references /&gt;</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=6458 2023-09-18T15:31:05Z

<p>Skaestle: Added more recent performance numbers</p> <hr /> <div>'''While having the security of Web3 blockchains, the performance of the Internet Computer (IC) is comparable to Web2 and cloud technology stacks. The IC far outperforms traditional blockchain protocols in efficiency.'''<br /> <br /> == Performance goals==<br /> A key objective of the Internet Computer is to provide a public compute layer that replaces traditional IT. A natural concern is that this will cause far less efficient computation.<br /> <br /> The Internet Computer works very differently to other blockchains, and is powered by advanced new cryptography. Internally, the network is able to strictly limit the replication of data and computation, while still providing the liveness and security guarantees expected of a blockchain. It also has the ability to assign different “trust levels” to units of blockchain code that it hosts (“smart contracts”), which changes the level of replication applied to their computations and data. In its current state of development, it is already orders of magnitude more efficient than other blockchains, but it is designed to eventually become more efficient that traditional IT too.<br /> <br /> Like all blockchains, the Internet Computer network directly applies replication, in combination with advanced cryptography, to create a tamperproof platform with better liveness guarantees than traditional IT. Yet, it also limits replication, while using the replication that occurs to drive efficiency, for example by scaling out “query” transactions.<br /> <br /> For example, a large online service might be built on Amazon Web Services using a database in a master-slave configuration, Kubernetes instances of web workers, memcached instances for caching the results of database queries, and a CDN (content distribution network) that caches web content they serve on the edge of the network. This already creates a large amount of replication without creating a tamperproof platform, nor providing liveness guarantees. For example, each slave node of the database replicates its computations and data, and regular snapshots will also be taken as backups, data used by the web workers is replicated by the memcached instances, and each work will also cache data in its memory, while the product of web queries will be replicated all over the world on CDN nodes.<br /> <br /> Because replication is at the core of the design of the Internet Computer, it can derive powerful security, liveness and other properties from replication, while also applying it more efficiently. For example, because the Internet Computer is a single logical blockchain and platform, as it grows larger, the utilization of the underlying node hardware upon which it runs can be made higher than, say, a standalone server machine in a data center. A key objective of the Internet Computer is, over time, to provide a public compute platform that provides a more power efficient way for the world to build systems and services.<br /> <br /> == Performance experiments == <br /> Scalability of the Internet Computer is facilitated by 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.<br /> <br /> '''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 just needs a response by a single node and does not require 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.<br /> <br /> == Test setup ==<br /> <br /> 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. <br /> 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. <br /> The experiment targeted all nodes in every subnet concurrently, much the same as what boundary nodes would be doing if they would be used.<br /> <br /> 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.<br /> <br /> == Measurements ==<br /> <br /> We evaluate the performance of the IC on a CD pipeline, which is running periodically. Those benchmarks target a single subnetwork with a configuration close to IC nodes on mainnet. We scale up those numbers to the current number of nodes and subnetworks on mainnet, which yields the following numbers:<br /> <br /> '''Query calls:''' 2'358'304 queries/s (5'669 queries/s per node scaled up to 33 subnetworks with 13 machines each)<br /> <br /> '''Update calls:''' 33'000 updates/s (1000 updates/s per subnetwork scaled up to 33 subnetworks)<br /> <br /> Last updated: '''September 18, 2023'''.<br /> <br /> All benchmark run against a small number of canister that simply return, as the goal of this benchmark is to measure throughput of the messaging subsystem and to determine runtime overhead of message processing.<br /> <br /> Canister code can be (almost) arbitrarily complex and therefor significantly lower the throughput if canister execution is becoming the bottleneck (and not messaging).<br /> <br /> ===Previous measurements ===<br /> The following measurements were made on '''May 24, 2022''', with 31 application subnets (having each 13 nodes) out of a total of 35 subnets (4 are system subnets such as the NNS and SNS subnets that have more nodes). Benchmarks where executed by simultaneously stressing all subnetworks on mainnet.<br /> <br /> ====Update calls====<br /> The Internet Computer sustained more than '''20'841 updates/second''' calls to application canisters for a period of four minutes (averaging '''672 updates/second''' per subnet).<br /> The update calls measured here are triggered from ingress messages sent from outside the IC.<br /> <br /> ====Query calls====<br /> Arguably more important are query calls, since they contribute to more than 90% of the traffic observed on the IC.<br /> The Internet Computer processed '''1'125'982 queries per second''' calls to application canisters (averaging '''2'792 queries per second''' per node).<br /> During the experiment each load is increased incrementally and run for a period of 5 minutes.<br /> <br /> <br /> ==Conclusion and next steps==<br /> The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC using:<br /> *More subnets: This will immediately 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.<br /> *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.<br /> <br /> ==See Also==<br /> *'''The Internet Computer project website (hosted on the IC): [https://internetcomputer.org/ internetcomputer.org]'''<br /> *[https://medium.com/dfinity/the-internet-computers-transaction-speed-and-finality-outpace-other-l1-blockchains-8e7d25e4b2ef The Internet Computer’s Transaction Speed and Finality Outpace Other L1 Blockchains]<br /> *[https://forum.dfinity.org/t/internet-computer-performance-dec-1-2021-load-testing/9240 Internet Computer Performance - Dec 1, 2021 Load testing]<br /> ===References=== <br /> &lt;references /&gt;</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=ICP_custody_with_Ledger_Nano&diff=4951 2023-04-19T13:43:48Z

<p>Skaestle: </p> <hr /> <div>== Ledger Nano ==<br /> <br /> The [https://www.ledger.com/ Ledger] Nano is one of the world’s most popular hardware wallets for safely storing crypto assets. A Ledger wallet combined with the Ledger Live app gives users complete control over their crypto, ensuring ownership over their assets while providing maximum security.<br /> <br /> == ICP and Ledger Nano==<br /> <br /> To use the Ledger Nano to manage your ICP follow these instructions, you need three things:<br /> <br /> * Networked computer <br /> * [https://identity.ic0.app/ Internet Identity] with [https://nns.ic0.app/v2/ NNS frontend dapp]<br /> * Ledger Nano<br /> <br /> You can follow the user manual here: [https://medium.com/dfinity/integrating-ledger-nano-with-the-nns-front-end-dapp-user-manual-9c5600925e16 Integrating Ledger Nano With the NNS Front-End Dapp]<br /> <br /> ==Features==<br /> <br /> The Ledger Nano + NNS dapp integration supports the following actions:<br /> <br /> * Receive/send ICP<br /> * Stake a neuron<br /> * View neurons<br /> * Add neurons as hotkeys<br /> * Dissolve neurons<br /> * Disburse neurons<br /> * Increase dissolve delay of neurons<br /> * View NNS proposals<br /> * Vote on NNS proposals<br /> * Choose neurons to follow for voting<br /> <br /> ==Benefits==<br /> <br /> * Maximum control of one's seed phrase (NNS frontend dapp does not access one's seed phrase)<br /> * Has all the functionality one needs for custody, staking, voting<br /> * Ideal for people who want to want to combine easy web experience with to control of their seedphrase ICP<br /> <br /> ==Trade-offs and risks==<br /> <br /> If you use this combination, you are accepting the following trade-offs:<br /> <br /> * '''Risk of losing access''' - If you only have lose access your Ledger Nano AND forget seed phrase, you lose access to your ICP.<br /> <br /> * '''Risk your devices do not support it''' - Not all devices and browsers support WebAuthn, so this option is sometimes not available. Supported browsers for Ledger Nano integration currently include Chrome (desktop) v89+, Edge v89+, and Opera v76+.<br /> <br /> == Security ==<br /> <br /> The Ledger Internet Computer (ICP) app was built by a collaboration between the [https://zondax.ch/ Zondax] team of engineers and cryptographers and the DFINITY Foundation. It was released and announced on December 3, 2021 [https://medium.com/dfinity/introducing-the-ledger-internet-computer-icp-app-for-nano-wallets-eed38c549f0d].<br /> <br /> The Ledger Internet Computer (ICP) app has undergone a third-party audit and has been reviewed and approved by Ledger. You can access the Ledger Internet Computer (ICP) app repository here: https://github.com/Zondax/ledger-icp.<br /> <br /> == See Also ==<br /> * [[Managing ICP holdings]]<br /> * [[ICP custody options]]</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=L1_comparison&diff=3948 2022-12-13T15:28:55Z

<p>Skaestle: Added max stack size</p> <hr /> <div>To get a view of the top performers in the blockchain industry, it's useful to compare across common metrics. Here we build a table that does such a comparison. All data correct as of December 2022. <br /> <br /> Metrics explanations and references are given below.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+ L1 Comparisons<br /> |-<br /> ! Metrics / L1 !! ICP !! ADA !! AVAX !! ALGO !! ETH !! NEAR !! SOL<br /> |-<br /> | TPS || 9’720 || 2.37 || 49.52 || 15.5 || 11.1 || 6 || 3000+ (381 excluding votes)<br /> |-<br /> | Finality || 1-2secs || 5-10mins || 2.3secs || 3.5secs || 15mins || 2.4secs || 5-12.8secs<br /> |-<br /> | Tx Cost || 0.0004 || 0.33 || 0.01 || 0.0003 || 0.57 || 0.0002 || 0.00025<br /> |-<br /> | Fixed tx cost || Yes || no || no || no || no || no || no<br /> |-<br /> | Energy Consumption || 0.008 || 51.59 || 4.76 || 2.7 || || || 0.166<br /> |-<br /> | On-Chain Storage || $5 (3.95T cycles x 1XDR) || $17,035 - $113,507 (53,236 – 354708ADA) || $206,875 (15,62 5AVAX) || || 15,494,409 (12,643.75 ETH) || || 48,625 (3,477.69 SOL)<br /> |-<br /> | Nodes / Validators || 549 || 1050 || 1195 || 1530 || || 798 || 1872<br /> |-<br /> | Nakamoto coefficient || || 22 || || || || || <br /> |-<br /> | repos, DAOs, dapps, tokens || [https://internetcomputer.org/showcase full web3] || [https://cexplorer.io/dapps nft &amp; defi] || || y || || y ||<br /> |-<br /> | Safety threshold || || 51% || || || || ||<br /> |-<br /> | Burnt fees || 443ICP || || 2,047,382.09AVAX || || || ||<br /> |-<br /> | Max stack size || 4 GiB || ?? || ?? || 4 MB || 32 KiB || 256 KiB ||<br /> |-<br /> | Max persisted memory || 52 GiB || ?? || ?? || 1 MB || 2^261 B (however, 15,494,409$ per GiB) || 32 KiB ||<br /> |}<br /> <br /> == Metrics ==<br /> * '''TPS''' measures the transactions processed per second<br /> * '''Finality''' measures the time taken for a block to be finalised<br /> * '''Tx Cost''' measures the cost of a transaction<br /> * '''Energy Consumption''' measures the energy consumption<br /> * '''On-Chain Storage''' measures the cost of storing data on-chain<br /> * '''Nodes/Validators''' measures the number of nodes<br /> * '''Nakamoto Coefficient''' is the count of malicious nodes needed to collude to prevent a blockchain from functioning properly<br /> * '''Market Cap''' is the price of the coin times the number of coins<br /> * '''Price''' denotes the dollar price of the coin<br /> * '''Circulating Supply''' is the count of coins in circulation<br /> * '''Volume''' is the amount transferred in a given period<br /> * '''Users''' counts the users on the network<br /> * '''Repos, DAOs, Dapps, Tokens''' showcases the leading applications supported by the network<br /> * '''Safety Threshold''' is the assumption underlying the safety property of a blockchain<br /> * '''Burnt Fees''' counts the amount of tokens burnt by fees<br /> <br /> == References == <br /> * '''ICP''' : [https://dashboard.internetcomputer.org IC Dashboard]<br /> * '''ADA''' : [https://explorer.cardano.org/en Cardano explorer] and [https://cexplorer.io/ cexplorer]<br /> * '''AVAX''' : [https://snowtrace.io/ Snowtrace] and [https://subnets.avax.network/ Avalanche explorer]<br /> * '''ALGO''' : [https://www.algorand.com/ Algorand website] and [https://metrics.algorand.org/ Algorand metrics site]<br /> * '''ETH''' : [https://etherscan.io/ Etherscan]<br /> * '''NEAR''' : [https://explorer.near.org/ Near explorer]<br /> * '''SOL''' : [https://solana.com/ Solana website] and [https://solanabeach.io/ Solana beach]</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Energy_Consumption_and_Sustainability&diff=3199 2022-10-11T14:53:16Z

<p>Skaestle: Added link to page with performance numbers.</p> <hr /> <div>= Energy consumption =<br /> <br /> The following is an approximation of mainnet power consumption.<br /> <br /> The average power consumption of an Internet Computer node is 700&amp;thinsp;W.<br /> <br /> If we assume a power usage effectiveness (PUE) [https://en.wikipedia.org/wiki/Power_usage_effectiveness 1], [https://energyinnovation.org/2020/03/17/how-much-energy-do-data-centers-really-use/ 2], of 2.33 that leads to a total power consumption of 1631.0&amp;thinsp;W including cooling and other data center operations costs.<br /> <br /> Given a total of 518 nodes and 11 boundary nodes in mainnet, resulting in a worst case of 862799W to operate all IC nodes for mainnet (including also system subnets).<br /> This is a worst case analysis for power consumption of nodes as we would normally expect them to throttle when not fully utilized and thereby reducing power consumption.<br /> Given the [[Internet_Computer_performance|maximum rate of update]]s and queries that we can currently support in the IC, one update call would consume 38.95&amp;thinsp;J (Joules) and one query call 0.59&amp;thinsp;J. These figures are for a hypothetically fully utilized IC.<br /> <br /> <br /> With the current approximate rate of 3300 transactions/s, the IC uses 261.45&amp;thinsp;J per transaction.<br /> <br /> In the future, the energy consumption will be much lower as the overhead of the system subnets will be comparatively smaller, boundary nodes will contain caching, and the replica software much more optimised.<br /> <br /> = Putting this in context =<br /> We see that even with conservative estimations, the energy consumption of the Internet Computer is substantially lower than competing blockchain projects, but also existing (highly optimized) web2 tech. See the table below to put IC performance in perspective.<br /> <br /> {| class=&quot;wikitable&quot;<br /> |+ Energy consumption comparison<br /> |-<br /> ! Source !! Cost (measured in Joules (J))<br /> |-<br /> | One Internet Computer transaction || 261&amp;thinsp;J<br /> |-<br /> | One Google search || 1'080&amp;thinsp;J&lt;ref&gt;https://store.chipkin.com/articles/did-you-know-it-takes-00003-kwh-per-google-search-and-more&lt;/ref&gt;<br /> |-<br /> | One Solana transaction || 1'837&amp;thinsp;J&lt;ref&gt;https://solana.com/news/solana-energy-usage-report-november-2021#ref1&lt;/ref&gt;<br /> |-<br /> | One Ethereum 2 transaction || 126'000&amp;thinsp;J&lt;ref&gt;https://blog.ethereum.org/2021/05/18/country-power-no-more/&lt;/ref&gt;<br /> |-<br /> | One Cardano transaction || 1'972'440&amp;thinsp;J&lt;ref&gt;https://www.trgdatacenters.com/most-environment-friendly-cryptocurrencies/&lt;/ref&gt;<br /> |-<br /> | One Ethereum transaction || 692'820'000&amp;thinsp;J&lt;ref&gt;https://digiconomist.net/ethereum-energy-consumption/&lt;/ref&gt;<br /> |-<br /> | One Bitcoin transaction || 6'995'592'000&amp;thinsp;J&lt;ref&gt;https://digiconomist.net/bitcoin-energy-consumption&lt;/ref&gt;<br /> |}</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance_%26_power_consumption&diff=3201 2022-10-07T10:12:37Z

<p>Skaestle: Skaestle moved page Internet Computer performance &amp; power consumption to Internet Computer performance over redirect: Decupling performance and energy consumption</p> <hr /> <div>#REDIRECT [[Internet Computer performance]]</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=3200 2022-10-07T10:12:37Z

<p>Skaestle: Skaestle moved page Internet Computer performance &amp; power consumption to Internet Computer performance over redirect: Decupling performance and energy consumption</p> <hr /> <div>'''While having the security of Web3 blockchains, the performance of the Internet Computer (IC) is comparable to Web2 and cloud technology stacks. The IC far outperforms traditional blockchain protocols in efficiency.'''<br /> <br /> == Performance goals==<br /> A key objective of the Internet Computer is to provide a public compute layer that replaces traditional IT. A natural concern is that this will cause far less efficient computation.<br /> <br /> The Internet Computer works very differently to other blockchains, and is powered by advanced new cryptography. Internally, the network is able to strictly limit the replication of data and computation, while still providing the liveness and security guarantees expected of a blockchain. It also has the ability to assign different “trust levels” to units of blockchain code that it hosts (“smart contracts”), which changes the level of replication applied to their computations and data. In its current state of development, it is already orders of magnitude more efficient than other blockchains, but it is designed to eventually become more efficient that traditional IT too.<br /> <br /> Like all blockchains, the Internet Computer network directly applies replication, in combination with advanced cryptography, to create a tamperproof platform with better liveness guarantees than traditional IT. Yet, it also limits replication, while using the replication that occurs to drive efficiency, for example by scaling out “query” transactions.<br /> <br /> For example, a large online service might be built on Amazon Web Services using a database in a master-slave configuration, Kubernetes instances of web workers, memcached instances for caching the results of database queries, and a CDN (content distribution network) that caches web content they serve on the edge of the network. This already creates a large amount of replication without creating a tamperproof platform, nor providing liveness guarantees. For example, each slave node of the database replicates its computations and data, and regular snapshots will also be taken as backups, data used by the web workers is replicated by the memcached instances, and each work will also cache data in its memory, while the product of web queries will be replicated all over the world on CDN nodes.<br /> <br /> Because replication is at the core of the design of the Internet Computer, it can derive powerful security, liveness and other properties from replication, while also applying it more efficiently. For example, because the Internet Computer is a single logical blockchain and platform, as it grows larger, the utilization of the underlying node hardware upon which it runs can be made higher than, say, a standalone server machine in a data center. A key objective of the Internet Computer is, over time, to provide a public compute platform that provides a more power efficient way for the world to build systems and services.<br /> <br /> == Performance experiments == <br /> Scalability of the Internet Computer is facilitated by 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.<br /> <br /> '''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 just needs a response by a single node and does not require 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.<br /> <br /> == Test setup ==<br /> <br /> 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. <br /> 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. <br /> The experiment targeted all nodes in every subnet concurrently, much the same as what boundary nodes would be doing if we would use them.<br /> <br /> 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.<br /> <br /> == Measurements ==<br /> <br /> The following measurements were made on May 24, 2022, with 31 application subnets (having each 13 nodes) out of a total of 35 subnets (4 are system subnets such as the NNS and SNS subnets that have more nodes).<br /> <br /> === Update calls ===<br /> The Internet Computer sustained more than '''20'841 updates/second''' calls to application canisters for a period of four minutes (averaging '''672 updates/second''' per subnet).<br /> The update calls measured here are triggered from ingress messages sent from outside the IC.<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute to more than 90% of the traffic observed on the IC.<br /> The Internet Computer processed '''1'125'982 queries per second''' calls to application canisters (averaging '''2'792 queries per second''' per node).<br /> During the experiment each load is increased incrementally and run for a period of 5 minutes.<br /> <br /> <br /> == Conclusion and next steps ==<br /> The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC using:<br /> * More subnets: This will immediately 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.<br /> * 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.<br /> <br /> ==See Also==<br /> <br /> * [https://medium.com/dfinity/the-internet-computers-transaction-speed-and-finality-outpace-other-l1-blockchains-8e7d25e4b2ef The Internet Computer’s Transaction Speed and Finality Outpace Other L1 Blockchains]<br /> * [https://forum.dfinity.org/t/internet-computer-performance-dec-1-2021-load-testing/9240 Internet Computer Performance - Dec 1, 2021 Load testing]<br /> === References === <br /> &lt;references /&gt;</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=3198 2022-10-07T10:12:02Z

<p>Skaestle: </p> <hr /> <div>'''While having the security of Web3 blockchains, the performance of the Internet Computer (IC) is comparable to Web2 and cloud technology stacks. The IC far outperforms traditional blockchain protocols in efficiency.'''<br /> <br /> == Performance goals==<br /> A key objective of the Internet Computer is to provide a public compute layer that replaces traditional IT. A natural concern is that this will cause far less efficient computation.<br /> <br /> The Internet Computer works very differently to other blockchains, and is powered by advanced new cryptography. Internally, the network is able to strictly limit the replication of data and computation, while still providing the liveness and security guarantees expected of a blockchain. It also has the ability to assign different “trust levels” to units of blockchain code that it hosts (“smart contracts”), which changes the level of replication applied to their computations and data. In its current state of development, it is already orders of magnitude more efficient than other blockchains, but it is designed to eventually become more efficient that traditional IT too.<br /> <br /> Like all blockchains, the Internet Computer network directly applies replication, in combination with advanced cryptography, to create a tamperproof platform with better liveness guarantees than traditional IT. Yet, it also limits replication, while using the replication that occurs to drive efficiency, for example by scaling out “query” transactions.<br /> <br /> For example, a large online service might be built on Amazon Web Services using a database in a master-slave configuration, Kubernetes instances of web workers, memcached instances for caching the results of database queries, and a CDN (content distribution network) that caches web content they serve on the edge of the network. This already creates a large amount of replication without creating a tamperproof platform, nor providing liveness guarantees. For example, each slave node of the database replicates its computations and data, and regular snapshots will also be taken as backups, data used by the web workers is replicated by the memcached instances, and each work will also cache data in its memory, while the product of web queries will be replicated all over the world on CDN nodes.<br /> <br /> Because replication is at the core of the design of the Internet Computer, it can derive powerful security, liveness and other properties from replication, while also applying it more efficiently. For example, because the Internet Computer is a single logical blockchain and platform, as it grows larger, the utilization of the underlying node hardware upon which it runs can be made higher than, say, a standalone server machine in a data center. A key objective of the Internet Computer is, over time, to provide a public compute platform that provides a more power efficient way for the world to build systems and services.<br /> <br /> == Performance experiments == <br /> Scalability of the Internet Computer is facilitated by 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.<br /> <br /> '''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 just needs a response by a single node and does not require 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.<br /> <br /> == Test setup ==<br /> <br /> 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. <br /> 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. <br /> The experiment targeted all nodes in every subnet concurrently, much the same as what boundary nodes would be doing if we would use them.<br /> <br /> 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.<br /> <br /> == Measurements ==<br /> <br /> The following measurements were made on May 24, 2022, with 31 application subnets (having each 13 nodes) out of a total of 35 subnets (4 are system subnets such as the NNS and SNS subnets that have more nodes).<br /> <br /> === Update calls ===<br /> The Internet Computer sustained more than '''20'841 updates/second''' calls to application canisters for a period of four minutes (averaging '''672 updates/second''' per subnet).<br /> The update calls measured here are triggered from ingress messages sent from outside the IC.<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute to more than 90% of the traffic observed on the IC.<br /> The Internet Computer processed '''1'125'982 queries per second''' calls to application canisters (averaging '''2'792 queries per second''' per node).<br /> During the experiment each load is increased incrementally and run for a period of 5 minutes.<br /> <br /> <br /> == Conclusion and next steps ==<br /> The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC using:<br /> * More subnets: This will immediately 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.<br /> * 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.<br /> <br /> ==See Also==<br /> <br /> * [https://medium.com/dfinity/the-internet-computers-transaction-speed-and-finality-outpace-other-l1-blockchains-8e7d25e4b2ef The Internet Computer’s Transaction Speed and Finality Outpace Other L1 Blockchains]<br /> * [https://forum.dfinity.org/t/internet-computer-performance-dec-1-2021-load-testing/9240 Internet Computer Performance - Dec 1, 2021 Load testing]<br /> === References === <br /> &lt;references /&gt;</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Limitless_Scaling&diff=3197 2022-10-07T08:31:13Z

<p>Skaestle: Removed sections on Finality and Consensus. Doesn&#039;t seem like this belongs here.</p> <hr /> <div>'''The Internet Computer (IC) can scale its capacity without limit, simply by adding additional nodes to fuel new subnets. Nodes are added via the Network Nervous System (NNS) which forms new subnets almost on a weekly basis since genesis. In contrast, most other blockchains have transaction limits baked into the protocol (e.g. adding more servers to Bitcoin does not increase its transaction volume) and need cumbersome layers to address scaling.<br /> <br /> See Internet Computer Dashboard: https://dashboard.internetcomputer.org/'''<br /> <br /> === Subnet Architecture ===<br /> <br /> The Internet Computer's scalability is enabled by sharding canisters and their state into subnets. Each subnet runs its own instance of state machine replication and can therefore process update and query calls independently from other subnets. <br /> While running independently, it is still possible for canister on different subnetworks to communicate with each other by means of Xnet communication.<br /> <br /> It's therefore possible to scale out by adding more IC nodes to the Internet Computer.<br /> * If new nodes are added as *new subnetworks*, more update calls be executed per time unit since the new subnetwork can process update calls independently from the rest of the system.<br /> * If new nodes are added to *existing subnetworks*, more queries can be executed per time unit. That is because query call, in contrast to update calls, are executed on individual machines, rather than replicated on all nodes of a subnetwork as with update calls.<br /> <br /> However, the finalization rate of the consensus layer and therefor the rate of update calls per second, might be negatively affected by a larger number of nodes in a subnetwork. That is because more data has to be exchanged between the larger number of nodes before consensus on the order of input messages can be reached.<br /> <br /> Further, having more subnetworks tends to decrease locality: the probability of needing to communicate across subnetworks increases.<br /> <br /> Consequently, the IC also must scale up by increasing performance on individual IC node machines. Example are scaling the IC runtime to efficiently utilize resources such as CPU and memory and achieving highly concurrent execution of independent canister calls.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=421 2021-11-10T13:06:01Z

<p>Skaestle: </p> <hr /> <div>This post describes the DFINITY foundation's performance evaluation of the Internet computer. <br /> We will periodically update the numbers in this article to reflect improvements we will achieve over time.<br /> <br /> Scalability of the Internet Computer comes from partitioning the IC into subnetworks.<br /> <br /> Subnetworks process update calls from Ingress messages independently from other subnetworks. They can scale up by adding more subnetworks at the cost of having more network traffic (as applications then need to potentially communicate across subnetworks). In its current form, the IC should be able to scale out to hundreds of subnetworks.<br /> <br /> Query calls are read-only calls that are processed locally on each node. Scalability comes from adding more nodes, either to an existing subnetwork (at the cost of making consensus i.e. update calls more expensive) or as new subnetworks.<br /> <br /> == Test setup ==<br /> <br /> We are running all of our experiments concurrently against all subnetworks other than the NNS and some of the most utilized application subnetworks to avoid disturbance of active IC users. <br /> We send load against those subnetworks directly and are not using boundary nodes for those experiments. Boundary nodes have additional rate limiting which is currently set slightly more conservative compared to what the IC can handle and running against them therefore is unsuitable for performance evaluation. <br /> We are targeting all nodes in each subnetwork concurrently, much the same as what boundary nodes would be doing if we would use them.<br /> <br /> We have installed one counter canister in each subnetwork. This counter canister is essentially a no-op canister. It only maintains a counter, which can be queries via a query call and incremented via update call. 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.<br /> <br /> <br /> == Measurements ==<br /> === Update calls ===<br /> <br /> The Internet Computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> The update calls we have been measuring here are triggered from Ingress messages sent from outside the IC.<br /> <br /> [[File:update-call-performance.png|1024px|Update Call Performance]]<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> [[File:query-call-performance.png|1024px|Query Call Performance]]<br /> <br /> The Internet Computer can currently process up to 250,000 queries per second.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.<br /> <br /> == Conclusion and next steps ==<br /> <br /> The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC by:<br /> <br /> * More subnetworks: This will immediate increase the query and update throughput. While adding subnetworks might eventually lead to other scalability problems, the IC in its current shape should be able to support hundreds of subnetworks.<br /> * 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 should be possible.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=420 2021-11-10T09:53:51Z

<p>Skaestle: /* Update calls */</p> <hr /> <div>This post describes our performance evaluation of the Internet computer. <br /> <br /> Scalability of the Internet Computer comes from partitioning the IC into subnetworks.<br /> <br /> Subnetworks process update calls from Ingress messages independently from other subnetworks. They can scale up by adding more subnetworks, which is at the cost of having more network traffic (as applications then need to potentially communicate across a network). In its current form, the IC should be able to scale out to hundreds of subnetworks.<br /> <br /> Query calls are read-only calls that are processed locally on each node. Scalability comes from adding more nodes, either to an existing subnetwork (at the cost of making consensus i.e. update calls more expensive) or as new subnetworks.<br /> <br /> We will periodically update the numbers in this article to reflect improvements we will achieve over time.<br /> <br /> == Test setup ==<br /> <br /> We are running all of our experiments concurrently against all subnetworks other than the NNS and some of the most utilized application subnetworks to avoid disturbance of active IC users. <br /> We send load against those subnetworks directly and are not using boundary nodes for those experiments. Boundary nodes have additional rate limiting which is currently set slightly more conservative compared to what the IC can handle and running against them therefore is unsuitable for performance evaluation. <br /> We are targeting all nodes in each subnetwork concurrently, much the same as what boundary nodes would be doing if we would use them.<br /> <br /> We have installed one counter canister in each subnetwork. This counter canister is essentially a no-op canister. It only maintains a counter, which can be queries via a query call and incremented via update call. 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.<br /> <br /> <br /> == Measurements ==<br /> === Update calls ===<br /> <br /> The Internet Computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> The update calls we have been measuring here are triggered from Ingress messages sent from outside the IC.<br /> <br /> [[File:update-call-performance.png|1024px|Update Call Performance]]<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> [[File:query-call-performance.png|1024px|Query Call Performance]]<br /> <br /> The Internet Computer can currently process up to 250,000 queries per second.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.<br /> <br /> == Conclusion and next steps ==<br /> <br /> The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC by:<br /> <br /> * More subnetworks: This will immediate increase the query and update throughput. While adding subnetworks might eventually lead to other scalability problems, the IC in its current shape should be able to support hundreds of subnetworks.<br /> * 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 should be possible.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=419 2021-11-10T09:40:06Z

<p>Skaestle: </p> <hr /> <div>This post describes our performance evaluation of the Internet computer. <br /> <br /> Scalability of the Internet Computer comes from partitioning the IC into subnetworks.<br /> <br /> Subnetworks process update calls from Ingress messages independently from other subnetworks. They can scale up by adding more subnetworks, which is at the cost of having more network traffic (as applications then need to potentially communicate across a network). In its current form, the IC should be able to scale out to hundreds of subnetworks.<br /> <br /> Query calls are read-only calls that are processed locally on each node. Scalability comes from adding more nodes, either to an existing subnetwork (at the cost of making consensus i.e. update calls more expensive) or as new subnetworks.<br /> <br /> We will periodically update the numbers in this article to reflect improvements we will achieve over time.<br /> <br /> == Test setup ==<br /> <br /> We are running all of our experiments concurrently against all subnetworks other than the NNS and some of the most utilized application subnetworks to avoid disturbance of active IC users. <br /> We send load against those subnetworks directly and are not using boundary nodes for those experiments. Boundary nodes have additional rate limiting which is currently set slightly more conservative compared to what the IC can handle and running against them therefore is unsuitable for performance evaluation. <br /> We are targeting all nodes in each subnetwork concurrently, much the same as what boundary nodes would be doing if we would use them.<br /> <br /> We have installed one counter canister in each subnetwork. This counter canister is essentially a no-op canister. It only maintains a counter, which can be queries via a query call and incremented via update call. 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.<br /> <br /> <br /> == Measurements ==<br /> === Update calls ===<br /> <br /> The Internet Computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> [[File:update-call-performance.png|1024px|Update Call Performance]]<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> [[File:query-call-performance.png|1024px|Query Call Performance]]<br /> <br /> The Internet Computer can currently process up to 250,000 queries per second.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.<br /> <br /> == Conclusion and next steps ==<br /> <br /> The Internet Computer today already shows impressive performance. On top of that, it should be possible to further scale out the IC by:<br /> <br /> * More subnetworks: This will immediate increase the query and update throughput. While adding subnetworks might eventually lead to other scalability problems, the IC in its current shape should be able to support hundreds of subnetworks.<br /> * 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 should be possible.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=418 2021-11-10T09:24:07Z

<p>Skaestle: </p> <hr /> <div>This post describes our performance evaluation of the Internet computer. <br /> <br /> Scalability of the Internet Computer comes from partitioning the IC into subnetworks.<br /> <br /> Subnetworks process update calls from Ingress messages independently from other subnetworks. They can scale up by adding more subnetworks, which is at the cost of having more network traffic (as applications then need to potentially communicate across a network). In its current form, the IC should be able to scale out to hundreds of subnetworks.<br /> <br /> Query calls are read-only calls that are processed locally on each node. Scalability comes from adding more nodes, either to an existing subnetwork (at the cost of making consensus i.e. update calls more expensive) or as new subnetworks.<br /> <br /> We will periodically update the numbers in this article to reflect improvements we will achieve over time.<br /> <br /> == Test setup ==<br /> <br /> We are running all of our experiments concurrently against all subnetworks other than the NNS and some of the most utilized application subnetworks to avoid disturbance of active IC users. <br /> We send load against those subnetworks directly and are not using boundary nodes for those experiments. Boundary nodes have additional rate limiting which is currently set slightly more conservative compared to what the IC can handle and running against them therefore is unsuitable for performance evaluation. <br /> We are targeting all nodes in each subnetwork concurrently, much the same as what boundary nodes would be doing if we would use them.<br /> <br /> We have installed one counter canister in each subnetwork. This counter canister is essentially a no-op canister. It only maintains a counter, which can be queries via a query call and incremented via update call. 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.<br /> <br /> <br /> == Measurements ==<br /> === Update calls ===<br /> <br /> The Internet Computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> [[File:update-call-performance.png|1024px|Update Call Performance]]<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> [[File:query-call-performance.png|1024px|Query Call Performance]]<br /> <br /> The Internet Computer can currently process up to 250,000 queries per second.<br /> We are working on several improvements to those numbers that should improve the query performance by at least one order of magnitude.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=281 2021-11-09T17:39:20Z

<p>Skaestle: </p> <hr /> <div>This post describes our performance evaluation of the Internet computer. <br /> <br /> Scalability Internet Computer comes from partitioning the IC into subnetworks.<br /> <br /> Subnetworks process update calls from Ingress messages independently from other subnetworks. They can scale up by adding more subnetworks, which is at the cost of having more network traffic (as applications then need to potentially communicate across a network). In its current form, the IC should be able to scale out to hundreds of subnetworks.<br /> <br /> Query calls are read-only calls that are processed locally on each node. Scalability comes from adding more nodes, either to an existing subnetwork (at the cost of making consensus i.e. update calls more expensive) or as new subnetworks.<br /> <br /> We will periodically update the numbers in this article to reflect improvements we will achieve over time.<br /> <br /> <br /> == Measurements ==<br /> === Update calls ===<br /> <br /> The Internet Computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> [[File:update-call-performance.png|1024px|Update Call Performance]]<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> [[File:query-call-performance.png|1024px|Query Call Performance]]<br /> <br /> The Internet Computer can currently process up to 250’000 queries per second.<br /> We are working on several improvements to those numbers that should improve the query performance by at least on order of magnitude.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=280 2021-11-09T17:37:15Z

<p>Skaestle: </p> <hr /> <div>== Measurements ==<br /> === Update calls ===<br /> <br /> The Internet Computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> [[File:update-call-performance.png|1024px|Update Call Performance]]<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> [[File:query-call-performance.png|1024px|Query Call Performance]]<br /> <br /> The Internet Computer can currently process up to 250’000 queries per second.<br /> We are working on several improvements to those numbers that should improve the query performance by at least on order of magnitude.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=279 2021-11-09T17:33:54Z

<p>Skaestle: </p> <hr /> <div>== Measurements ==<br /> === Update calls ===<br /> <br /> The Internet Computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> [[File:update-call-performance.png|Update Call Performance]]<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> [[File:query-call-performance.png|Query Call Performance]]<br /> <br /> The Internet Computer can currently process up to 250’000 queries per second.<br /> We are working on several improvements to those numbers that should improve the query performance by at least on order of magnitude.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=File:Query-call-performance.png&diff=278 2021-11-09T17:32:51Z

<p>Skaestle: </p> <hr /> <div></div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=File:Update-call-performance.png&diff=277 2021-11-09T17:32:31Z

<p>Skaestle: </p> <hr /> <div></div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=276 2021-11-09T17:31:39Z

<p>Skaestle: </p> <hr /> <div>== Measurements ==<br /> === Update calls ===<br /> <br /> The Internet Computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> <br /> <br /> The Internet Computer can currently process up to 250’000 queries per second.<br /> We are working on several improvements to those numbers that should improve the query performance by at least on order of magnitude.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_performance&diff=275 2021-11-09T17:31:02Z

<p>Skaestle: This page describes the performance of the Internet Computer.~</p> <hr /> <div>== Measurements ==<br /> === Update calls ===<br /> <br /> The internet computer can currently sustain more than 11000 updates/second for a period of four minutes, with peaks over 11500 updates/second.<br /> <br /> === Query calls ===<br /> Arguably more important are query calls, since they contribute with more than 90% of the traffic we are observing on the IC.<br /> <br /> The internet computer can currently process up to 250’000 queries per second.<br /> We are working on several improvements to those numbers that should improve the query performance by at least on order of magnitude.<br /> During our experiments, we increment the load incrementally and run each load for a period of 5 minutes.</div>

Skaestle https://wiki.internetcomputer.org/w/index.php?title=Internet_Computer_wiki&diff=274 2021-11-09T17:29:24Z

<p>Skaestle: </p> <hr /> <div>&lt;strong&gt;Welcome to the Internet Computer Wiki!&lt;/strong&gt; Feel free to join in. All are welcome!<br /> <br /> <br /> = Topics Central =<br /> <br /> * [[Internet computer]]<br /> * [[Index of dapps on the Internet Computer]]<br /> * [[ICP token]]<br /> * [https://dashboard.internetcomputer.org/ Internet Computer dashboard] <br /> * [[Internet Computer Performance]]<br /> * [[DFINITY]]<br /> <br /> == For blockchain &amp; crypto enthusiasts ==<br /> * [[Myths and facts]]<br /> * [[The cryptography behind the Internet Computer]]<br /> * [https://www.reddit.com/r/dfinity/ r/dfinity]<br /> * [[How to stake on the Internet computer]]<br /> * [[Tokenomics of the Internet Computer]]<br /> * [[Governance of the Internet Computer]]<br /> <br /> == For dapp developers ==<br /> * [[Internet Computer for dapp developers]]<br /> * [[Best practices for NFT drops]]<br /> * [https://forum.dfinity.org/ IC community developer forum]<br /> <br /> == For computer scientists ==<br /> * [[The Internet Computer for Computer Scientists]]<br /> <br /> == For node owners ==<br /> * [[Internet Computer for node owners]]<br /> <br /> = FAQs =<br /> <br /> * [[FAQ]]<br /> <br /> '''Computer Scientists FAQ'''<br /> * [[The Internet Computer for Computer Scientists]]<br /> <br /> <br /> <br /> == Using the wiki ==<br /> Consult the [https://www.mediawiki.org/wiki/Special:MyLanguage/Help:Contents User's Guide] for information on using the wiki software.<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Configuration_settings Configuration settings list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:FAQ MediaWiki FAQ]<br /> * [https://lists.wikimedia.org/postorius/lists/mediawiki-announce.lists.wikimedia.org/ MediaWiki release mailing list]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Localisation#Translation_resources Localise MediaWiki for your language]<br /> * [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Combating_spam Learn how to combat spam on your wiki]<br /> <br /> Use this page to test editing<br /> * [[Test editing the Internet Computer Wiki]]</div>

Skaestle