Node+Express+MongoDB Native Client Performance issue

Question

I am testing the performance of Node.js (ExpressJS/Fastify), Python (Flask) and Java (Spring Boot with webflux) with MongoDB. I hosted all these sample applications on the same server one after another so all services have the same environment. I used two different tools Load-test and Apache Benchmark cli for measuring the performance.

All the code for the Node sample is present in this repository: benchmark-nodejs-mongodb

I have executed multiple tests with various combinations of the number of requests and concurrent requests with both the tools

Apache Benchmark Total 1K requests and 100 concurrent

ab -k -n 1000 -c 100 http://{{server}}:7102/api/case1/1000

Load-Test Total 100 requests and 10 concurrent

loadtest http://{{server}}:7102/api/case1/1000 -n 100 -c 10

The results are also attached to the Github repository and are shocking for NodeJS as compared to other technologies, either the requests are breaking in between the test or the completion of the test is taking too much time.

Server Configuration: Not dedicated but

CPU: Core i7 8th Gen 12 Core RAM: 32GB Storage: 2TB HDD Network Bandwidth: 30Mbps

Mongo Server Different nodes on different networks connected through the Internet

Please help me in understanding this issue in detail. I do understand how the Event loop works in nodejs but this problem is not identifiable.

Reproduced

Setup:

• Mongodb Atlas M30
• AWS c4xlarge in the same region

Results:

No failures

Document Path:          /api/case1/1000
Document Length:        37 bytes

Concurrency Level:      100
Time taken for tests:   33.915 seconds
Complete requests:      1000
Failed requests:        0
Keep-Alive requests:    1000
Total transferred:      265000 bytes
HTML transferred:       37000 bytes
Requests per second:    29.49 [#/sec] (mean)
Time per request:       3391.491 [ms] (mean)
Time per request:       33.915 [ms] (mean, across all concurrent requests)
Transfer rate:          7.63 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   3.1      0      12
Processing:   194 3299 1263.1   3019    8976
Waiting:      190 3299 1263.1   3019    8976
Total:        195 3300 1264.0   3019    8976

Length failures on havier load:

Document Path:          /api/case1/5000
Document Length:        37 bytes

Concurrency Level:      100
Time taken for tests:   176.851 seconds
Complete requests:      1000
Failed requests:        22
   (Connect: 0, Receive: 0, Length: 22, Exceptions: 0)
Keep-Alive requests:    978
Total transferred:      259170 bytes
HTML transferred:       36186 bytes
Requests per second:    5.65 [#/sec] (mean)
Time per request:       17685.149 [ms] (mean)
Time per request:       176.851 [ms] (mean, across all concurrent requests)
Transfer rate:          1.43 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    0   0.9      0       4
Processing:   654 17081 5544.0  16660   37911
Waiting:      650 17323 5290.9  16925   37911
Total:        654 17081 5544.1  16660   37911

Answer 1

If you are using only single server, then you can cache the database operations on the app side and get rid of database latency altogether and only commit to it with an interval or when cache expires.

If there are multiple servers, you may get help from a scalable cache, maybe Redis. Redis alao has client caching and you can still apply your own cache on Redis to boost the performance further.

A plain LRU cache written in NodeJs can do at least 3-5 million lookups per second and even more if key access is based on integers(so it can be sharded like an n-way associative lru cache).

If you group multiple clients into single cache request, then getting help from C++ app can reach hundreds of millions to billions of lookups per second depending on data type.

You can also try sharding the db on extra disk drives like ramdisk if db data is temporary.

Event loop can be offloaded a task queue for database operations and another queue for incoming requests. This way event loop can harness i/o overlapping more, instead of making a client wait for own db operation.

Answer 2

I copied results of your tests from the github repo for completeness:

Python

Java Spring Webflux

Node Native Mongo

So, there are 3 problems.

Upload bandwidth

ab -k -n 1000 -c 100 http://{{server}}:7102/api/case1/1000 uploads circa 700 MB of bson data over the wire.

30Mb/s = less than 4MB/s which requires at least 100 seconds only to transfer data at top speed. If you test it from home, consumer grade ISP do not always give you the max speed, especially to upload.

It's usually less a problem for servers, especially if application is hosted close to the database. I put some stats for the app and mongo servers hosted on aws in the same zone in the question itself.

Failed requests

All I could notice are "Length" failures - the number of bytes factually received does not match.

It happens only to the last batch (100 requests) because some race conditions in nodejs cluster module - the master closes connections to the worker threads before worker's http.response.end() writes data to the socket. On TCP level it looks like this:

After 46 seconds of struggles there is no HTTP 200 OK, only FIN, ACK.

This is very easy to fix by using nginx reverse proxy + number of nodejs workers started manually instead of built-in cluster module, or let k8s do resource management.

In short - don't use nodejs cluster module for network-intensive tasks.

Timeout

It's ab timeout. When network is a limiting factor and you increase the payload x5 - increase default timeout (30 sec) at least x4:

ab -s 120 -k -n 1000 -c 100 http://{{server}}:7102/api/case1/5000

I am sure you did this for other tests, since you report 99 sec/request for java and 81 sec/request for python.

Conclusion

There are nothing shockingly bad with nodejs. Some bugs in the cluster, but it's a very niche usecase to start from, and it's trivial to work it around.

The flamechart:

Most of the CPU time is used to serialise/deserialise bson and send data to the stream, with some 10% spent on the most CPU intensive bson serialiseInto,