@brandonferens well, you can use sessions for some of the things but for things like saving queries results and heavy-to-compute you should really use Cache. Use redis, it can be used both for session storage and caching and it also persists to disk so if you redis server crashes you can get all the data back including the sessions which is amazing. It's also super fast just like memcached. The only gotcha is that it is single threaded so if you plan to use multiple core server for your redis server you may want to set up multiple listening workers on the server so it will be able to use all of the cores. Nonetheless, it is still ridiculously fast even while its single threaded. By the way, it worth mentioning that most caches such as memcached and redis are O(1) when it comes for storing and fetching data from :)
Storing Stuff in the Session. Good idea?
I really like using the Session to store stuff that needs to persist across a user's entire visit to my site. Like Auth data. However, my question is, at what point, it storing stuff in the Session to much?
I need to show the user some percentages, so I run a query once and save that to the Session. I need to show that the user completed stuff. I run the query once, and save those completions to the Session. etc.
These seem fine to me, but I am building something that could need to have 200 completions saved to the Session, or more. I am looking around Laracasts and there is a lot of crossover as to aggregated data and metrics. How is it done rightly? How is it done quickly and efficiently (meaning server, not programming)? And how is it done with scalability in mind?
Thanks for any help, direction, opinions, or ideas!
I think for things like this, considering your user is already logged in (and has an ID), you'd be better off storing stuff like this in the cache - Then it persists between logins.
Saving things to the session should be kept for the most basic and sparse of data if you can help it so you don't hit any storage limits.
Run your query once, then store the result in the cache, using an identifier that includes the current user's user id like so:
$logged_in_user = Auth::user();
// Retrieve the information you want for this user.
$query = DB::table('mytable')->where('user_id', '=', $logged_in_user->id)->get(); // Pretend this returns 2000 rows!
// Save the results of that query to the cache.
// The cache key is made up of an identifier, a dot, then the user ID.
Cache::forever("my_big_statistics_query.{$logged_in_user->id}", $query);
Then you can retrieve the value any time using:
$logged_in_user = Auth::user();
$stats = Cache::get("my_big_statistics_query.{$logged_in_user->id}");
Thanks @kfirba, I haven't really had a need to pull the trigger on Redis, but this seems like a good option.
@danmatthews, I like the approach. I have been wanting to move some queries over to getting cached. If the user updates something that would affect the cache, just destroy it and recreate it.
@brandonferens yep that's what i would do and it's pretty much the cornerstone of modern web app caching - unless something has changed, grab it from the cache and not from the database if you can help it.
PS you can use Redis as your cache backend too.
Please or to participate in this conversation.