Shulou(Shulou.com)06/01 Report--

The index of this series of articles is "the Tao spell of responsive Spring".

Previously on Spring WebFlux Quick get started | Spring WebFlux performance Test | Spring WebClient performance Test

Source code of this article

1.4.4 performance comparison between synchronous and Asynchronous Database drivers

Many databases have launched official asynchronous drivers. In Spring Data Reactive, asynchronous drivers of Mongo, Casandra, Redis and CouchDB have been integrated.

For an example of using Reactive Mongo in Spring WebFlux, see Spring WebFlux Quick start.

In this section, we look at the advantages of asynchronous drivers by using YSCB to benchmark the performance of synchronous and asynchronous drivers for MongoDB.

YCSB (Yahoo! Cloud Serving Benchmark) is an open source performance benchmark tool for testing various cloud services / NoSQL/ key-value pairs. YCSB is great and easy to use, so let's just follow the introduction of wiki.

1) prepare YCSB

If you use Windows, please refer to here to pre-install the necessary software and tools.

There are two ways to obtain YCSB. One is to download the compressed package directly:

Curl-O-location https://github.com/brianfrankcooper/YCSB/releases/download/0.12.0/ycsb-0.12.0.tar.gztar xfvz ycsb-0.12.0.tar.gzcd ycsb-0.12.0

The other is based on source code:

Git clone git://github.com/brianfrankcooper/YCSB.gitcd YCSBmvn clean package

At this point, you can use the bin/ycsb command for performance testing, run:

Usage: bin/ycsb command databse [options] Commands: load Execute the load phase run Execute the transaction phase shell Interactive mode...

As you can see from the command help above, we can run three kinds of commands:

Load, which performs data loading, that is, saving data to the database; run, which performs transactions such as updates, queries, etc.; and shell, which can run tests interactively.

The test in this section mainly uses load and run for batch operation of data, first loading the dataset with the load command, and then using the run command to test the data operation. In YCSB, the workload of the test is defined by the workload file. We see several configuration files for workload [amurf] under workloads, such as workloada:

# Yahoo! Cloud System Benchmark# Workload A: Update heavy workload# Application example: Session store recording recent actions# # Read/update ratio: 50 fields 5 bytes each Default data size: 1 KB records (10 fields, 100 bytes each, plus key) # Request distribution: zipfianrecordcount=1000operationcount=1000workload=com.yahoo.ycsb.workloads.CoreWorkloadreadallfields=truereadproportion=0.5updateproportion=0.5scanproportion=0insertproportion=0requestdistribution=zipfian

You can see that the profile defines the number of records, the number of operations, and the percentage of different operations. For example, both readproportion and updateproportion above are 50%. As can be seen from the comments, this simulates a scenario with frequent update operations, and can simulate a scenario in which session is saved in Web applications.

Several workload configurations simulate different scenarios with different proportions of read/update/scan/insert operations.

We can run the performance test of the workloada-based load phase on mongo with the following command:

Bin/ycsb load mongodb-P workloads/workloada

The default is to connect to the mongodb database of localhost:27017. If you want to specify the database connection information, you can specify it with the-p parameter:

Bin/ycsb load mongodb-P workloads/workloada\-p "mongodb.url=mongodb://192.168.0.101:27017/ycsb?w=1&maxPoolSize=32&waitQueueMultiple=20"

The maximum number of connection pools and the maximum number of waits are also specified.

Of course, we can also overwrite the values in the workloada file with command parameters, such as:

Bin/ycsb load mongodb-P workloads/workloada\-p "mongodb.url=mongodb://192.168.0.101/ycsb?w=1&maxPoolSize=32&waitQueueMultiple=20"\-p recordcount=10000-p operationcount=10000-threads 20

In addition, the number of concurrent threads is specified as 20 with-threads.

These are the contents of this test. For more information about the use of YCSB, please refer to wiki.

2) prepare for the test

The goal of this test is to compare the performance of Mongodb synchronous and asynchronous drivers, for simplicity, in terms of throughput and average operating time. Vertically

Compare the effects of different numbers of concurrent threads on the two data; observe the changes in the number of connections during the test.

The change in the number of connections can be observed through the mongostat command, as shown in the following figure:

The mongo-benchmark.sh running above is a convenient testing script based on the bin/ycsb command, and outputs some summary data (including throughput and tie operation duration) for easy viewing. At the same time, the details of each output of the bin/ycsb command are saved to a file in the output directory.

The script can be found in the code base, and if mongo runs on localhost:27017, it can be executed directly with the following command (in the same directory as bin):

Curl https://raw.githubusercontent.com/get-set/get-reactive/master/ycsb-mongo-shell/mongo-benchmark.sh | bash

At the top of the figure is a test of load and run based on workloada for synchronous and asynchronous drivers respectively, and below is the output of mongostat (one line per second). The four stages marked by the four orange × × boxes can be found from the numbers of insert, query and update. From these data, we can analyze:

Load mainly loads data sets, so you will see an increase in the number of insert, which adds up to the test preset of 30000 pieces of data; similar run is mainly used for operational testing based on workload, and workloada is a 50 workloada 50 read/update, which is also reflected in the output of mongostat. The throughput of synchronous and asynchronous drivers in load phase is 19801 and 25554 respectively. The throughput of synchronous and asynchronous drivers in load phase is 25706 and 27675 respectively, which is slightly lower than that of synchronous drivers. Looking at the average duration of insert, read and update operations, we can draw the same conclusion. This test sets up 20 threads to operate on the mongo database. You can see the change in the number of database connections in the conn column of the mongostat output. For synchronous drivers, the number of connections will increase from 4 to 25, while for asynchronous drivers, the number of connections will increase from 4 to 7.

In this way, the performance data of the two drivers are observed for different number of threads and the number of connections is recorded through the data of mongostat.

There is no limit on the number of connections.

To observe the change in the number of connections, don't limit maxPoolSize (comment on the MAX_POOL_SIZE=8 line in the script). The final results are as follows:

In the figure, the left and right columns of each color are synchronous and asynchronous data, respectively. For the sake of intuition, let's compare it with a chart:

First compare the throughput of the load phase and the run phase (the higher the column, the better)

It can be found that when the number of threads reaches 8, the growth trend of throughput basically disappears, especially the throughput of synchronous drivers decreases slightly as the number of threads continues to increase. I don't know whether it has anything to do with the CPU with four cores and eight threads in the test environment.

Then compare the average duration of INSERT, READ, and UPDATE operations (the lower the column, the better)

Relatively speaking, asynchronous drivers can lead to faster read and write operations, especially when dealing with more and more threads.

Finally, compare the number of connections.

The comparison of the number of connections is even more obvious: in the case of synchronization, the number of connections = number of threads + 5, while in the case of async, the number of connections is almost always kept at 7. If there is no comparison, there is no harm.

II. Limit the number of connections

Next, limit the number of connections to 32 and test the performance data of the synchronous driver when the number of threads ranges from 30 to 80:

By chart comparison:

It can be seen that after limiting the number of connections, there is a slight improvement, but compared with asynchronous drivers, there is still a certain gap.

3) conclusion

First of all, it should be noted that the above is not a test for database tuning, here we only tested workloada (you can modify the WORKLOAD variable in the script if you are interested, and then test other scenarios), and there is no special basis to limit the number of connections to 32, and 32 is not the optimal number of connections for the machine tested.

Through the tests in this section, we can draw the following two conclusions for the MongoDB driver:

Compared to synchronous drivers, asynchronous drivers are slightly better in performance; when dealing with a large number of client threads, asynchronous drivers can cope with a small but stable number of connections, which means less memory consumption (each connection consumes stack size memory space, and the stack size is 10m by default). 1.4.4 Summary

Above, we compared synchronous and asynchronous tests for Http server, Http client and database. To sum up, responsive applications or drivers based on asynchronous non-blocking can respond to highly concurrent requests or calls with a small number of fixed threads, and can provide higher performance than multi-threaded concurrent scenarios.

Responsive and non-blocking do not always make applications run faster, and building code as a non-blocking execution itself carries a small cost. However, responsive and non-blocking applications can often play a role in applications with high concurrency, less computing and intensive I-WEB applications. Especially in micro-service applications, the effect will be more amazing in the case of more network I _ map O.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.