Is it a good practice uses the InMemory.Storage in a production environment?

[MatheusXavier]

I'm using the Health Checks UI in a container with the InMemory.Storage and I'm not sure about how much memory it uses. Is it a good practice uses the InMemory.Storage in a production environment? Or this could be a bad choice because the container can demands a lot resources?

PS.: I'm opening this issue because I read the documentation and didn't see any topics talking about that.

[devax]

Unless you have a huge amount (read dozens or hundreds) of endpoints you're monitoring in combination with these endpoints changing state very often, I can't imagine that memory consumption should be noticeably high. You obviously lose the state history when the UI gets restarted, but this seems not to be a concern for you. Just let it run for a couple of days/weeks and observe your memory consumption. If concerned or if it turns out to be an issue, you could schedule regular restarts of your front end to clear the state.

[lonix1]

Do you have any experience to share, now that you've been running in production for a while? I'm also interested in this.

The key question is how many events are stored in the in-memory provider? Is there a way to limit to say, 100 events, or are ALL events stored forever?

Any advice would be appreciated!

[MatheusXavier]

We are currently monitoring only 7 services and they rarely change their status so there is not much data to save and when you do a new deploy basically reset those statuses helping this resource consumption too, so far we haven't had any problem using the InMemory approach.

I saw that when you are using the database approach you can configure how many events you want to show on the dashboard, this can help performance but I don't know if there is a configuration of how many events are stored in the in-memory provider.

[sungam3r]

Closing as answered.