Recently I was playing around with cls-rtracer, my small library for Express and Koa. This library is just a collection of lightweight middlewares built on top of cls-hooked. So basically I was testing the footprint of cls-hooked (and Async Hooks API, as I was using version 8 of Node.js).
I've implemented a very simple Express app and tested it on my machine with and without CLS. The scenario with CLS was the following:
- On each request an id was generated with uuid/v4 and then stored in CLS. This was done by the cls-rtracer middleware.
- In the route middleware, there was some logging done with winston, a logger library. The library was configured to obtain the request id from CLS and append it for each log entry.
The load was generated by ab utility. I was using Windows 10 and Node.js 10, but also tested on a Ubuntu VM with Node.js 8 and got similar results.
As the result, I got about 10-15% RPS (request per second) degradation with request ids and CLS turned on. As for CPU utilization, I didn't see any major difference, like sudden spikes, between these two scenarios.
I've published my test app as a gist: https://gist.github.com/puzpuzpuz/3c2a36ca0835906ad50dbd22c72df974
Looks like a late response, but it may help someone in future. These scenarios should be quite close to real-world apps.
2020 update. Starting from v12.7.0 Node.js includes AsyncLocalStorage API. This CLS core API has significantly lower footprint when compared with cls-hooked
and other CLS libraries.