Query and update call latency

​​There are two types of messages that can be sent to a smart contract running on the Internet Computer: queries and updates. Queries are non-committing, so all state changes are discarded after execution. State changes of an update message are committed after successful execution and discarded on failure.

Queries and update calls can be served at web speed. Improving their performance is a key objective of DFINITY's research team and the broader Internet Computer ecosystem.

Query latency

Query latency is a complex topic as there is a long sequence of events happening between a user's web browser making a request and the result is rendered on the user's screen.

Here is a simplified view of what happens when a user makes a request to a smart contract running on a subnet blockchain on the Internet Computer. The main contributors to the time it takes until the result is visible on the user's display are as follows:

1. The network communication between the user's web browser and the Internet Computer boundary node the browser connects to. This latency also applies to traditional web apps and is influenced by several factors. The first factor is the geographical proximity between the user and the boundary node. In many cases, this will improve as more boundary nodes are added to the Internet Computer. Another factor is the quality of the network connection. This is mainly a function of the user's ISP. For example, the network connection can also be significantly slower on a mobile device. Finally, there are other factors, such as whether or not this is the first request and an SSL connection needs to be established with the boundary node.
2. The network communication between the boundary node and an Internet Computer replica participating in a subnet blockchain that hosts the smart contract that the user requests. This latency is under the control of the Internet Computer and will improve as data centers that contribute nodes to the Internet Computer improve their Internet connectivity with dedicated bandwidth.
3. Waiting for execution. If the smart contract receives many queries, then some queries may need to wait in the queue until execution of previous queries completes. The waiting duration ranges from milliseconds to seconds depending on query execution speed. An important property of queries is that a smart contract can process multiple queries at the same time in parallel. Thus the waiting duration for queries is typically much lower compared to the waiting duration of update messages.
4. The actual execution. The duration depends on the Wasm code of the smart contract. Specifically, it depends on the number of instructions that the Wasm method of the smart contract executes and the amount of memory it accesses. For example, a query that reads and returns a few kilobytes of data will finish in a few milliseconds. On the other hand, a query that accesses megabytes and executes millions of instructions may run for hundreds of milliseconds.
5. The network communication between the Internet Computer replica and the boundary node to send the result of the query.
6. The network communication between the boundary node and the web browser to send the result of the query.
7. Processing of the query result and rendering in the web browser. This part is similar to traditional web applications. Slow JavaScript code may drastically increase the rendering time.

The user may choose to run a query in the replicated mode, where it is executed on all replicas to make sure that the result was not tampered with. In such a case the latency of the query increases and is similar to the latency of update calls described below. Note that certified variables are another way to ensure tamper-proof results without increasing the latency.

Update call latency

Each update message goes through the consensus protocol to ensure that the state of the smart contract changes in a secure and tamper-proof way. The latency of an update messages depends on the following:

1. The network communication between the user's web browser and the Internet Computer boundary node the browser connects to. This part is the same as for queries.
2. The network communication between the boundary node and an Internet Computer replica participating in a subnet blockchain that hosts the smart contract that the user requests. After this step, the message is added into the queue of received messages of the replica and the HTTP request completes successfully. Subsequent processing of the message happens asynchronously. The user can get the status of the call by polling the corresponding read_state HTTP endpoint.
3. Peer-to-peer communication between replicas to propagate the update message to the eventual block maker in the subnet. This step may take up to hundreds of milliseconds depending on the network between data centers.
4. Consensus protocol round to add the update message to the next block.
5. Waiting for execution. Depending on the compute-allocation of the smart contract and the number of already queued update messages for the smart contract, this may take zero or more rounds. Note that a smart contract processes update messages sequentially, one by one.
6. The actual execution. During an execution round all replicas execute the same messages, in the same order, starting from the same initial state. It is important that execution is deterministic so that all replicas get the same result and end up in the same final state. Similar to queries, the duration of execution depends on the actual Wasm code and on how many instructions it executes.
7. Consensus protocol round for a majority of replicas to agree on the final state, including results.
8. Waiting for execution. Depending on the compute-allocation of the smart contract and the number of already queued update messages for the smart contract, this may take zero or more rounds. Note that a smart contract processes update messages sequentially, one by one.
9. Consensus protocol round for a majority of replicas to agree on the final state, including results.

Thus, in addition to the network round trip time to a replica (and polling latency), processing an update message takes at least two consensus rounds. If the update message sends inter-canister messages, then the number of rounds increases correspondingly. The actual duration depends on the block finalization rate of the subnet. The typical rate is one block per second, which means that the typical update message latency is about 2-3 seconds.

Web speed

"Web speed" is not a precise concept. When talking about the web speed it is important to distinguish between requests that read data and transactions that change the state of a geographically distributed system. These operations have different latency expectations: the former are nearly instantaneous and should finish within tens of milliseconds while the latter may take up to a few seconds to ensure consistency of the changes.

As described above, query and updates of the Internet Computer match these expectations.