rud
commented
6 years ago Somebody please correct me if I'm wrong. Storing a "large" object in RequestStore should not have any impact on performance. The controller and request object instances are both going to be around for the duration of the request, and storing another reference is no problem.
RequestStore is handy when you have something you need across layers without passing a lot of explicit context around. For instance, maybe you need access to current_user in a model to do proper audit logging conveniently. That's at least one use-case I've come across.
What's a good pattern for storing objects in the RequestStore?
I'm currently investigating server slowness for one of the apps I'm working on and one of the main causes could possibly be the incorrect usage of RequestStore. It's just a matter of fixing things, but I'm pretty sure it's not a good idea to store references to things such as:
Controller
Request Context - get_request_context(request)
Aside from the controller storing, breaks MVC. It seems like it can propagate issues beyond the controller lifecycle. Being it, hard to unit test -- maybe. But I'd like to understand what's happening under the hood, aside from my app, the way thread local storage is used when the app is running on a server such as passenger.
Below this line, I might write things I don't truly understand, so please correct me if I'm wrong.
The server is running on passenger, and some searching have sent me to
https://github.com/steveklabnik/request_store/issues/39
https://stackoverflow.com/questions/7896298/safety-of-thread-current-usage-in-rails
I want to take a step back, just to raise the question that, is this even a good way to use RequestStore?
Storing other things like a User object makes sense, but storing big things might cause trouble for the ruby GC. And, does it lead to performance issues (high CPU usage) from garbage collection on a huge object?
Thank you so much, if you could help. Like I said, I might not understand everything yet but I really appreciate any input.