[Feature Request] Official Option to disable sourceMapCache

performance
1

Hi all,

I have a feature request or idea. It would be nice to have an option to disable sourceMapCache in order to minimize the servers RAM usage when in production.

Since RAM prices are rising, hosting is also becoming more expensive. Hetzner just raised their prices (cf. https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/) and also scalingo is taking subtle measures that ultimately lead to higher costs for hosting the same apps or development environments (like no more free starter containers, upcoming disabling of caching etc).

I spent some time optimizing my meteor 3.5 app, and noticed that, looking at heap snapshots, the sourceMapCache ate up almost 100 MB of heap. I implemented a hacky deployment script that factors this out, and the results in saving baseline memory consumption are quite remarkable in meteor 3.5: Disabling server source maps reduced heap usage from 408 MB to 190 MB (−53.4%), RSS by ~339 MB, and cgroup memory by ~370 MB. Now I can easily scale down a few containers that I use for staging and save quite a few bucks (however, of course, debugging now requires me to locally look up errors using app.js.map)

2 Likes
2

There’s many inefficiencies and outdated technologies and techniques from how the server source maps are generated to how they are loaded, parsed, and used in error stack traces that needs to be redesigned at some point. How the server bundle is loaded also seems to waste a lot of memory too. The more I’ve learned about this part of Meteor the more I’ve realized it needs a careful review and modernization.

If anyone else wants to easily check how much memory source maps or the server bundle are using in their app (among other things like publications, observers, and caches), Monti APM can show this in the heap snapshot analysis (use the new UI and go to tools > memory > create new heap snapshot). Though source maps are lazily loaded as needed, so the memory can grow over time as more errors are created with different stack traces.

3 Likes
3

I think it would be a really good improvement for the scalability of meteor apps, alongside with more efficient pubs via change streams and a more efficient base line memory usage.