RPC vs WebSocket Performance

A Comparison between WebSocket and RPC Connections in Web3js

Published in

51nodes

5 min readJun 23, 2020

Following the build a minimal Quorum network article we decided to utilize the newly added WebSocket connections to see how the differences between RPC and WebSockets play out in a blockchain environment.

In this article, we will explain how to set up a testing environment and how to run the test scenarios we provided. Further, we will measure differences in provider response times and analyze the results.

For the performance tests, we will use the contracts of the Drizzle Trufflebox as they are quite simple and accessible for everyone. You will also be able to use the Drizzle UI to interact with the Quorum network and the contracts.

Spoiler Alert! Web3 deprecated http connections as they do not support subscriptions.

Quorum Network

The first component for our testing environment is the Quorum network. Clone the repository and bring up the network using:

# Caution! For this you will need to have installed Docker and         Docker Compose.git clone https://github.com/51nodes/quorum-local-raft-network.gitcd quorum-local-raft-network/docker-compose up -d

This will set up 3 Quorum nodes which you can access via:

docker exec -it <container_name> geth attach ./qdata/dd/geth.ipc

note that each of the three nodes has an RPC and a WebSocket port. Those ports are 22000, 22001, 22002 for RPC and 23000, 23001, 23002 for WebSocket.

Accessing Drizzle-UI

Now that the network is running you can clone this article’s testing repository which includes the Drizzle Truffle Box and testing scripts.

git clone https://github.com/51nodes/drizzlebox-provider-performance.git

In the directory /app/src you can view the drizzleOptions.js which shows the network node we are accessing.

To run the tests and use the UI we need to install the required dependencies. In the root directory of the cloned drizzlebox-provider-performance project run:

# Caution! For this you will need to have installed Node.js.npm install

Now deploy the contracts using:

npm run deploy-contract-quorumlocal

And finally, you should be able to start the UI in the /app/src directory with:

npm installnpm run start

Connect to the Drizzle UI via Metamask by creating a Custom RPC connection to the Quorum network.

Now import an Account using the following private Key:

E6181CAAFFFF94A09D7E332FC8DA9884D99902C7874EB74354BDCADF411929F1

After importing the account make sure you have it selected and reload the Page. You will now be able to monitor contract interactions.

Testing Scenarios

In the performance directory of the test repository, you will find the readWritePerformanceTest.js script which includes four different testing functions. These are split into two functions for writing and two functions for reading transaction calls to the SimpleStorage contract. Depending on the executed function you can either set the storage value a single time or 30 times in a row. The same is true for reading the storage.

Running the Tests

In the /performance directory you can run the different tests with the following commands:

For <providerType> you can choose between rpc and ws.node readWritePerformanceTest <providerType> writeSinglenode readWritePerformanceTest <providerType> writeMultiplenode readWritePerformanceTest <providerType> readSinglenode readWritePerformanceTest <providerType> readMultiple

After running the writeSingle function you can check back on the UI to verify if the storage is set to 1.

Results and Takeaways

Writing Performance

Starting with writing to the storage for a single time there is a small difference between both provider types. Executing the single write we mostly get a delta margin of about 1–5ms in favor of the WebSocket, which in most cases resembles an advantage of 5% to 10%.

Looking at the results of writing to the storage for multiple times in a row, we can start to see a noticeable difference in response times. The WebSocket seems to take 10–50ms less to finalize than the RPC. Percentages also start to vary vastly. They are scattered in a range from 3% up to 17% in favor of the WebSocket.

Reading Performance

Strangely reading from the storage for a single time doesn’t yield a measurable difference. Execution times do vary slightly but in both directions so there is no real result to extract.

Coming to the multiple storage reads, the results get more stable. The response delta is ranging from 15–20ms. Which in most cases results in a 15% to 20% advantage for the WebSocket.

Takeaways

These results cover tests on my local machine (macOS) running on a 2,3GHz Intel Core i5 8259U processor and 8GB of 2133MHz RAM. So they fulfill the purpose of an academic comparison instead of a realistic testing scenario.

If we look at the results there is a small difference in running single writes while there is no measurable difference in single reads. Notable performance changes start to occur whilst running multiple requests to a WebSocket instead of an RPC connection. Multiple Writes to the SimpleStorage contract show that the WebSocket is on average 10% faster than the RPC. Multiple Reads from the storage reveal the advantages of the WebSocket connection are even higher with about 15–20% faster response times.

So generally speaking, you will be on the safe side with the WebSocket as it is about 10–20% faster than the RPC connection.

51nodes GmbH based in Stuttgart is a provider of crypto economy solutions.

51nodes supports companies and other organizations in realizing their Blockchain projects. 51nodes offers technical consulting and implementation with a focus on smart contracts, decentralized apps (DApps), integration of Blockchain with industry applications, and tokenization of assets.