Here are the results of some bench tests performed
on event-source project.
System
Node.js 16.14.0 Mongodb 4.3.1
Execution
Run the command npm run test:bench. This is starting a
simple Node.js process on transpiled source code.
Memory is measured with @airbnb/node-memwatch.
Timings are given in milliseconds and following this format: min, average, median, max.
Results
The bench executed without any MongoDb request does not
have any memory footprint (-410.12 kb and
0.004426 0.01 0.005017 4.862484)
10 000iterations of10parallel requests
MongoDb driver is having a footprint.
await db.collection('rooms').insertOne({
room_id: roomId,
quantity: 5
});
- memory:
920.85 kb. - timings:
1.187653 1.91 1.5412265 41.494594/ ite.
10 000iterations of10parallel requests
The creation of an entity is producing the following metrics:
- memory:
1.59 mb - timings:
7.283733 10.71 9.450872 60.666319 - overhead:
x5.61
10 000iterations of10parallel requests
After removing the await during state persistence,
metrics are:
- memory:
2.08 mb - timings:
7.132994 10.35 9.2597865 57.032342 - overhead:
x5.41
Impact is present but seems negligible.
10 000iterations of10parallel requests
Returning just after getState.
- memory:
1.06 mb - timings:
2.998191 4.64 3.89404 36.152782 - overhead:
x2.42
10 000iterations of10parallel requests
Returning just after getStateCollection.findOne
in getState method.
- memory:
1.023 mb - timings:
1.226146 2.07 1.5936015000000001 24.922473 - overhead:
x1.08
10 000iterations of10parallel requests
Fetching all events at once instead of using a
FindCursor and returning after getState.
- memory:
1.08 mb - timings:
3.00193 4.66 3.9399865 37.755536 - overhead:
x2.42
NO IMPACT
1 000iterations of10parallel requests
Update a single entity with retry set on 5s.
- memory:
1.66 mb - timings:
22.506913 31.37 28.827257000000003 143.544612 - overhead:
x16.42
10 000iterations of1parallel requests
Update a single entity with retry set on 5s.
- memory:
1.41 mb - timings:
15.00593 21.1 20.03355 160.40924 - overhead:
x11.04