Why the warning against in-memory in Prod?

[Garrett-R]

In the docs, it says in-memory storage is "only meant for testing/development and should be replaced with an appropriate storage of your choice before moving to production".

Why is that? Is it because, if you have multiple workers, then the rate limiting will only be on a per-worker basis (given a worker can only see its own memory)?

I'd prefer not to have to make a round-trip network call. So, I'm fine with the rate not being exact, i.e. being a per-worker rate limit.

[alisaifee]

There have been issues raised in the past around accidentally shipping the in-memory storage since it is the default and not getting the expected rate limits since "1/hour/user" distributed across n worker processes ends up meaning ~ "n/hour/user".

The warning is simply there to ensure everyone gets a heads up early on.

Additionally, the in-memory storage implementation was mostly intended to be a reference implementation and is probably not as optimized as it could be.

[alisaifee]

I just remembered that I had put this in - if you explicitly set storage_uri="memory://" when initializing the extension (or by using a flask config) - the warning won't be emitted.

[Garrett-R]

Makes sense, thank you!

[Bloos]

Hi,
I've got a similar problem. We've got a production application using mod_wsgi and multiple processes. We've added a new computationally expensive endpoint and therefore want to rate limit it. Hosting a memcached server for this single purpose seems like an overkill. Is there a way to use a File as storage backend similar to the FileSystemCache of flask-caching? Or even better: Is it possible to abstract the whole storage backend/caching stuff away by using flask-caching for it?

[alisaifee]

The backend storage is abstracted out to limits.

Using flask-caching is not viable since it would:

1. couple the rate limiting implementation to flask (which is the reason that part is kept separate in the limits library)
2. flask-caching only supports get/set operations which aren't sufficient for rate limiting as some kind of atomic increment or lock or transaction is the needed for a fixed window rate limit and list operations are needed for moving window implementations.

If you have any ideas on how to implement any of the rate limiting strategies using a file system I'm open to a pull request (it would go to the limits repository).

[Bloos]

Thanks for your quick response. I decided to go for the clean solution and added a memcached server. As I've said I'm also using flask-caching with a filesystem based cache, which I could also replace by memcached.