New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
High CPU usage when enabling"prettyPrint" #1458
Comments
How deep/complicated are your JSON objects? util.inspect, which is what we use for pretty print, could become very slow for sufficiently complicated objects (maybe even infinite loop if there are cyclical structures). Do you need to log your entire object, or would you be happy with just the first few layers of it (depth parameter)? |
Right now the JSON structures I am logging are essentially an array of objects; objects are instanced classes, their number are from 10 to 100 items and their complexity never reaches a depth level of 3 (no cyclical structures). However I log them very often: reaching the max frequency of one log each 200/500 ms. The logging of complex structures is only usefull on development environment when using "silly" verbosity. I didn't know "util.inspect" could be so slow compared to a JSON.stringify; problably a depth parameter could be enough to remove the spike (I could test it on my spare time if you need more data to understand better the situation) |
I'm going to leave this open because we should add some docs to winston or logform. From the Node.js docs on util.inspect (https://nodejs.org/api/util.html#util_util_inspect_object_options):
So Node recommends not using that in production code, hence we should probably mention somewhere that users shouldn't use prettyPrint in production code. That said, I bet if we exposed a depth parameter for prettyPrint, it could help performance. Thanks for bringing this up, I think it's an important note! |
Please tell us about your environment:
What is the problem?
When having intense logging using multiple JSON structures and prettyPrint option enabled, winston would spike the CPU to 90%+
Using the following configured transport to reproduce the problem:
Could be related to #613
What do you expect to happen instead?
No CPU spike using Winston and prettyPrint enabled
Other information
By disabling the prettyPrint or using stringified versions of the JSON structures before logging, the CPU spikes disappear completly.
Modified transport configuration to solve the CPU spikes:
The text was updated successfully, but these errors were encountered: