(9) Performance test of asynchronous MONGO driver--response spring's DAO spell device

This series of articles index the "Response Spring's word Wizard"
Previously summary Spring Webflux Quick Start | Spring Webflux Performance Test | Spring WebClient performance test
This article source

Performance comparison of 1.4.4 synchronous and asynchronous database drives

Many databases have been launched by the official asynchronous drive, in spring Data reactive, has integrated the MONGO, Casandra, Redis, couchdb asynchronous drivers.

Examples of using reactive MONGO in spring Webflux see Spring Webflux Quick Start.

In this section we observe the benefits of asynchronous drives by using YSCB's synchronous and asynchronous performance benchmarks for MongoDB.

YCSB (Yahoo! Cloud serving Benchmark) is an open source for Yahoo to test a variety of cloud services/nosql/key-value storage performance benchmark tool. YCSB is very good, very simple to use, we follow the wiki introduction to operate.

1) Prepare YCSB

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

There are two ways to get 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 built on source code:

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

At this point you can use the bin/ycsb command to perform the performance test and run it:

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

From the command help above we can see that we can run three kinds of commands:

• Load, perform data loading, i.e. save data to the database;
• Run, perform transactions, such as updates, queries, etc.;
• Shell, you can run the tests interactively.

The tests in this section mainly use load and run to perform bulk operations of the data, load the dataset with the Load command, and then test the data operation using the Run command. In YCSB, the workload of the test is defined by the workload file. We see workloads Several configuration files under the workload[a-f], such as Workloada:

# Yahoo! Cloud System Benchmark# Workload A: Update heavy workload#   Application example: Session store recording recent actions#                        #   Read/update ratio: 50/50#   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

The visible profile defines the number of record bars, the number of operations, and the percentage of different operations. For example, the top readproportion and updateproportion all are 50%, as can be seen from the note, this simulation is a more frequent update operation of the scene, you can simulate the Web application to save the session of the scene.

Several workload configurations simulate different scenarios with different read/update/scan/insert operating ratios.

We can run a performance test on MONGO based on the Workloada load phase with the following command:

bin/ycsb load mongodb -P workloads/workloada

The default is a connected localhost:27017 MongoDB database, and if you want to specify database connection information, you can specify it with the-p parameter:

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

Of course, we can also overwrite the values in the Workloada file with the 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

Additionally, the -threads number of concurrent threads specified is 20.

These are the content that this test will use, and more about the use of YCSB please refer to the wiki.

2) Prepare the test

The goal of this test is to compare the performance of MongoDB synchronous and asynchronous drives, as measured by two data per throughput and average operation . Vertically,

• Compare the impact of different numbers of concurrent threads on two data;
• Observe the changes in the number of connections during testing.

Changes to the number of connections can be mongostat observed by command, as shown in:

The top runs a mongo-benchmark.sh bin/ycsb script that is easy to test based on command writing, and outputs some summary data (including throughput and draw operation duration) for easy viewing, and also saves the details of each bin/ycsb command output to a output file in the directory.
The script can be found in the code base, and if MONGO is running localhost:27017 , it can be executed directly with the following command (in the bin same directory):

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

Above the figure is the synchronous drive and the asynchronous drive respectively ran a test based on workloada load and run, below is mongostat the output (one line per second), from, insert , query update The number can find out four orange XXX box marked 4 stages. With this data we can analyze:

• Load is the main load of the data set, so you will see more insert numbers, add up to test the preset 30,000 data; a similar run is primarily a workload-based operation Test, Workloada is a 50/50 read/update, It is also reflected in the output of Mongostat.
• The load phase synchronous and asynchronous drive throughput of 19801 and 25554,run phase synchronous and asynchronous throughput is 25706 and 27675, respectively, synchronous driver is slightly less, and then observe the average length of INSERT, read and update operations, you can draw the same conclusion.
• This test set 20 threads to operate the MONGO database, in the MONGOSTAT output conn column can see the number of database connections changes, for synchronous drive, the number of connections will increase from 4 to 25, and for the asynchronous driver, the number of connections will be increased from 4 to 7.

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

One, no limit the number of connections

To observe the changes in the number of connections, do not limit maxPoolSize (comment on the line in the script MAX_POOL_SIZE=8 ). The final result is as follows:

In the diagram, the left and right columns of each color are synchronous and asynchronous data, respectively. For the sake of intuition, let's compare it by graphs:

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

It can be found that when the number of threads reaches 8, the growth trend of throughput basically disappears, especially the synchronous drive throughput will decrease slightly with the number of threads continuing to increase. It is not known whether the test environment is related to a four-core eight-thread CPU.

Then compare the average length of insert, read, and update operations (the lower the bar is, the better)

In contrast, asynchronous drives can provide faster read and write operations, especially when dealing with more and more threads.

Finally, compare the number of connections

The number of connections is more pronounced: for synchronization, the number of connections = number of threads +5, and for asynchronous cases, the number of connections has remained almost 7. There is no harm without comparison.

Second, limit the number of connections

Below, limit the number of connections to 32, and test the number of threads from 30-80 for synchronous drive performance data:

Compare by chart:

Visible, after limiting the number of connections, slightly improved, but compared to the asynchronous drive, there is still a certain gap.

3) Conclusion

First of all, it's important to note that the above is not a test for database tuning, we only tested Workloada (if you are interested in modifying variables in the script and WORKLOAD then testing other scenarios), and there is no special basis for restricting the number of connections to 32, and for testing machines, 32 is not the optimal number of connections.

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

• Asynchronous drives are notch above in terms of performance relative to synchronous drives;
• In the case of a large number of client threads, the asynchronous drive can respond with a small number of stable connections, which means less memory consumption (each connection consumes the stack size's memory space, and the stack size is 10M by default).

1.4.4 Summary

Above, we have synchronized and asynchronous test comparisons for HTTP server, HTTP client, and database, which are based on asynchronous non-blocking responsive applications or drivers capable of thread executes high concurrent requests or calls with a small number of fixed lines, for scenarios where there is a blocking scenario, can provide higher performance than multithreaded concurrency scenarios.

Responsiveness and non-blocking do not always allow applications to run faster, and building code as a non-blocking execution itself can bring a small amount of cost. But in high-concurrency, low-compute, and I/O-intensive applications like Web applications, responsiveness and non-blocking can often be useful. Especially in micro-service applications, the network I/O is more than the case, the effect will be more amazing.

(9) Performance test of asynchronous MONGO driver--response spring's DAO spell device