Problem: In order to support accepting a function for options.msg,
express-winston is calling _.template for every request. This compiles
a brand new lodash template every request. Under heavy load, this has
significant performance and memory usage implications.
Solution: During initialization, make the decision on whether to use
a single cached template or a dynamic function that compiles a template
for each request. This way, we get the efficiency of a precompiled
template for the more common use cases, while remaining backwards
compatible with published features.
In a future version, it might be worth considering dropping support
for mustache formatting and just have express-winston consumers always
provide a function if they want a custom options.msg. The api consumer
can use JS template literals if they need templating in their custom
message.
Problem: In order to support accepting a function for options.msg, express-winston is calling
_.template
for every request. This compiles a brand new lodash template every request. Under heavy load, this has significant performance and memory usage implications.Solution: During initialization, make the decision on whether to use a single cached template or a dynamic function that compiles a template for each request. This way, we get the efficiency of a precompiled template for the more common use cases, while remaining backwards compatible with published features.
In a future version, it might be worth considering dropping support for mustache formatting and just have express-winston consumers always provide a function if they want a custom options.msg. The api consumer can use JS template literals if they need templating in their custom message.