Storing user info in sessions or nah?

[cmd]

Just a little question to get people's preferences (it's always good to see different opinions) so I was just wondering when it comes to games what are peoples preferences? Do you prefer to either store the users energy, will, brave, money etc in sessions or just keep retrieving from the database?

[Coly010]

Only thing I store in the session is a Boolean for if they logged in and an int for their userid.

Other things get stored in the db.

Why? Because if you store it all in session you have to update all the DB records anyway so it persists after session is destroyed

[KyleMassacre]

How about chaching them using memcached?

i have not used memcached yet but have briefly looked through some docs for it and seems pretty nice so I wouldn't know if there are any drawbacks to it.

From what hat I have seen though you just set the cache time and if it's about to expire, before you load the stat save it to the db. If it has expired, pull it from the db then cache it again. It seems as if it would work pretty well in reality

Edited August 20, 2015 by KyleMassacre

[cmd]

Good point, but do you not think rather than having to constantly retrieve the users money, username constantly to be displayed in the top bar it would be better to just store in session?

- - - Updated - - -

 

How about chaching them using memcached?

i have not used memcached yet but have briefly looked through some docs for it and seems pretty nice so I wouldn't know if there are any drawbacks to it.

From what hat I have seen though you just set the cache time and if it's about to expire, before you load the stat save it to the db. If it has expired, pull it from the db then cache it again. It seems as if it would work pretty well in reality

Nice idea, but using ASP.NET their is an alternative for this which is a global method.. Session_End.. says it in its name.. surely you can achieve the same thing? Just insert everything in the DB when the Session_End is called right?

[KyleMassacre]

I wouldn't know since I'm not familiar with .NET. I wasn't aware that we were talking about that. I think coly was on the same track as myself :p.

Play around with it and see if it's worth using I guess would be my answer. I wouldn't in PHP because it seems like handling a session may be a lot more of a pain in the ass than it's worth.

[Coly010]

I wouldn't know since I'm not familiar with .NET. I wasn't aware that we were talking about that. I think coly was on the same track as myself :p.

Play around with it and see if it's worth using I guess would be my answer. I wouldn't in PHP because it seems like handling a session may be a lot more of a pain in the ass than it's worth.

I was indeed on the same track as Kyle.

Talking PHP wise, if you want to store them in $_SESSION, be my guest, it'll take up memory though.

Your page will most likely make calls to select something from the database relating to users table, so i dont feel the need when i can just include those fields that appear often.

If you were storing only static values in $_SESSION, thats a different matter. Values that arent going to change. their userid, username, email etc. but i wouldnt store fields that are changing.

as for storing it in cache, what happens if someone deletes their browser cache?

[KyleMassacre]

Memcached is not the same as browser cache, it is its own system like a little mini db. I don't think it's as resource intensive as MySQL so it could be a nice little replacement for it in some aspects. But in actuality, I don't think the really meant for the way I suggested because it is cache which isn't supposed to change all that much like user stats. But on the flip side you could use it for offline players so your not hitting the db with query after query on something that isn't changing all the time when their profile is being looked up.

[Guest]

Cache is temporary data, so it's nothing like a replacement for mysql, redis on the otherhand can handle sessions.

You do you store a bool if they are logged in and an int? Surely if they aren't logged in the int would be 0 or null?

[Coly010]

Cache is temporary data, so it's nothing like a replacement for mysql, redis on the otherhand can handle sessions.

You do you store a bool if they are logged in and an int? Surely if they aren't logged in the int would be 0 or null?

It's because of how the application is set up, I know that if an int is 0 then if(int) would return false.

[Dayo]

Memcached get saved to memory from what i remember so as your game gets larger you will run our of resources quicker plus you have to handle power outages/reboots.

$_SESSION is a file store so everytime you want to access/update that data you have to perform a read/write to that file so depending on your hardware config it actually may be slower. Plus the problem with this is this data is only accessible on that single server, where as if you store it in a database you can access it from any server.

[KyleMassacre]

Memcached get saved to memory from what i remember so as your game gets larger you will run our of resources quicker plus you have to handle power outages/reboots.

$_SESSION is a file store so everytime you want to access/update that data you have to perform a read/write to that file so depending on your hardware config it actually may be slower. Plus the problem with this is this data is only accessible on that single server, where as if you store it in a database you can access it from any server.

Thats why I suggested possible both Memcache and a database. Here is something that I was proposing:

• Finding Stats
  
  • Search Memcached for the key
    
    • If found, Use it
      
    • If not found grab it from the database
      

     

   

  [*]Setting Stats

  • Are the stats going to expire?
    
    • Set them in the database
      

     

    [*]No?

    • Just display them from cache
      

     

   

Like I said, its probably best for offline players just because of the constant changes

[IllegalPigeon]

I was indeed on the same track as Kyle.

Talking PHP wise, if you want to store them in $_SESSION, be my guest, it'll take up memory though.

That's not how PHP sessions work. Your memory is safe.

Thats why I suggested possible both Memcache and a database. Here is something that I was proposing:

• Finding Stats
  
  • Search Memcached for the key
    
    • If found, Use it
      
    • If not found grab it from the database
      

  [*]Setting Stats

  • Are the stats going to expire?
    
    • Set them in the database
      

    [*]No?

    • Just display them from cache
      

Like I said, its probably best for offline players just because of the constant changes

You're over-thinking. There is such a thing as too much of a good thing, you know? Memcache is great, but it stores things in memory, it's all well and good using memcache but what happens when you exhaust all of your memory because you thought storing EVERYTHING in memcache was a great idea?

A general rule of thumb to go by when storing data in memory is to store large queries, anything that does a large calculation or queries that have a habit of being slow for whatever reason. Storing tiny bits of data in memory is just pointless and you end up using more of that precious memory you need. Also, it's worth mentioning that memchase uses a "Least recently used" reclamation algorithm. This means that if you start to run out of memory, memcahce will start replacing stored objects that haven't been used in a while. If you're storing some small user bits like "general information", the user makes a small change say "username", then you don't use it in a while, it'll get over-written.

Doing a data lookup in memcached isn't largely quicker than doing a database lookup. Cache is quicker, however, under high load, as it can handle more requests than your database can.

I strongly encourage using memcache, just don't go over the top.

[KyleMassacre]

Your right except we are not talking about storing everything. We are talking about storing user stats like health, money, xp, etc. I wasnt talking about storing the entire database in cache because of the constant updates

[IllegalPigeon]

Ah, I miss-read some things. Either way, my comment still stands. *IF* you have enough traffic on your site that means using cache to fetch something like the users health is actually beneficial (which I extremely doubt), then you're still going to be burning through mass amounts of memory. At which point, you'd need to add more servers dedicated to cache.

Seriously, small things like user stats, you do not need cache for. Use cache for bigger objects/more complex queries. I understand the concern over reducing database hits, but, memory is also very precious and doesn't come in "unlimited" forms and, I assure you, you're going to run in to data being over-written because it's not been used in a long time.

Edited August 23, 2015 by IllegalPigeon

[Coly010]

That's not how PHP sessions work. Your memory is safe.

Not exactly. Every variable you set uses memory. So the more data you store in the $_SESSION (which is a global variable) the more memory you will use.

[IllegalPigeon]

Not exactly. Every variable you set uses memory. So the more data you store in the $_SESSION (which is a global variable) the more memory you will use.

Lol, what. So, you're saying, if I set too many variables, I'm going to run out of memory?

PHP sessions do not use memory. So, yes, exactly.

You do know how sessions work, right?

[Coly010]

Lol, what. So, you're saying, if I set too many variables, I'm going to run out of memory?

PHP sessions do not use memory. So, yes, exactly.

You do know how sessions work, right?

So, what you are saying to me is that if I have 1GB RAM on a server and i try to execute this code:

ob_start();
for($_SESSION['iterator'] = 0; $_SESSION['iterator'] < 3000000000; $_SESSION['iterator']++;){
   echo $_SESSION['iterator']."\r\n";
}
ob_end_flush();

 

it'll run completely?

just gonna drop this answer here also... http://stackoverflow.com/a/17558888

its not about writing the session, its about reading from it.

I know that you probably think that i've linked an answer that agrees with what you were saying. It has in a sense, but in another it has agreed with me.

When writing the Session Data it gets stored on disk space, when reading the data again, memory gets used.

As this is a game and the session read from a lot it is going to use memory.

[IllegalPigeon]

So, what you are saying to me is that if I have 1GB RAM on a server and i try to execute this code:

ob_start();
for($_SESSION['iterator'] = 0; $_SESSION['iterator'] < 3000000000; $_SESSION['iterator']++;){
   echo $_SESSION['iterator']."\r\n";
}
ob_end_flush();

it'll run completely?

just gonna drop this answer here also... http://stackoverflow.com/a/17558888

its not about writing the session, its about reading from it.

I know that you probably think that i've linked an answer that agrees with what you were saying. It has in a sense, but in another it has agreed with me.

When writing the Session Data it gets stored on disk space, when reading the data again, memory gets used.

As this is a game and the session read from a lot it is going to use memory.

Yeah, so, the link you just gave completely agrees with me. It's as simple as that.

Your example is completely redundant, too, because you're going to run into ANY of those issues running ANYTHING for 3 billion iterations.

I just ran your code on a machine with 512MB RAM, I only did 1,000,000 iterations though because the problem now is rendering it in the browser, it'll take too long. Oh, what a surprise, I'm right. Run this. Tell me the results, the memory is pretty much exactly the same.

<?php

echo memory_get_usage() . '<br />';

for($_SESSION['iterator'] = 0; $_SESSION['iterator'] < 1000000; $_SESSION['iterator']++){
   echo $_SESSION['iterator'] . '<br />';
}

echo 'Memory: ' . memory_get_usage();

?>

Your original comment was "if you want to store them in $_SESSION, be my guest, it'll take up memory though.", which I pointed out is WRONG. It is wrong. Storing stuff in a session won't cause any issues at all. However, if for some reason, you're reading 3,000,000,000 session files per page load, then yeah, you've got a problem.

Also, your last comment assumes that the OP is loading EVERY stored session data for every page load. Why would you do that? Just like a query, you fetch the data you want. So, store 3,000,000,000 sessions files if your filesystem can handle it if you really want. But the fact is, I'm still right. Your original comment was "STORING" data in a session, not reading AND writing/best methods to fetch the data.

Also, the fact that you had to Google the answer and still get it wrong shows me that you have little understanding of sessions.

Edited August 23, 2015 by IllegalPigeon

[TheMasterGeneral]

Memory: 240440, in about 3 seconds

doiwin?

[/obvious sarcasm]

[IllegalPigeon]

Memory: 240440, in about 3 seconds

doiwin?

[/obvious sarcasm]

Yeah, but, what was the starting memory? The very first number ;) rendering in the browser will take a couple of seconds, but that's your browser and that's obvious if you're rendering 1 million numbers!

[TheMasterGeneral]

239496, or roughly 234KB.

What made me chuckle a little bit about the script, was, about halfway scrolling right, the page was like "nope, i'm done showing you sh*t"

:P

[IllegalPigeon]

239496, or roughly 234KB.

What made me chuckle a little bit about the script, was, about halfway scrolling right, the page was like "nope, i'm done showing you sh*t"

:P

Yeah, so, like I said...memory is BARELY touched. And that's to be expected with 1,000,000 sessions. But you see my point! Sessions won't affect the memory. Calling 1,000,000 sessions will, but, same for calling 1,000,000 cache entries and 1,000,000 database entries!

[Coly010]

Yeah, so, like I said...memory is BARELY touched. And that's to be expected with 1,000,000 sessions. But you see my point! Sessions won't affect the memory. Calling 1,000,000 sessions will, but, same for calling 1,000,000 cache entries and 1,000,000 database entries!

I never said that him storing his data in the session would take up all his memory, I just said it would use it, as from what was previous my understanding was that assigning a value to a variable uses memory. And it was my understanding that $_SESSION was a global variable and hence it would use memory.

Also, memory does get used, so I'm still correct in thinking that it would use memory, it just doesn't use enough to crash the server? Yes you are right about not having to worry about memory, but by going down that the route of storing and reading data from sessions you will use memory.

I will admit I stand corrected because what I had believed was wrong. I always knew that sessions where written in files.

Also, it the answer I got from Google doesnt "completely" agree with you. Did you miss out the part that said it uses memory when reading the data? No, you didn't you just ignored it because you focused solely on the storing of data, whereas I was looking at the bigger picture. You wouldn't store data in a session if you don't intend to read it again.

Anyway, thats my last post on the subject. I stand somewhat corrected.

[CaptainQuack]

Talking PHP wise, if you want to store them in $_SESSION, be my guest, it'll take up memory though.

The whole premise for your argument was that storing data in a session will take up memory. You were insinuating that it will take enough memory to be detrimental to the application. Now that it's been proven that you're wrong you're now suggesting that when the session file is read it will use memory. Well, duh. Every action that you process will use memory, that's what it's for.

 

Did you miss out the part that said it uses memory when reading the data? No, you didn't you just ignored it because you focused solely on the storing of data, whereas I was looking at the bigger picture. You wouldn't store data in a session if you don't intend to read it again.

Duh, again. You're obsessed with memory usage, of course reading a file will use it just not enough to even warrant you saying it.

 

as for storing it in cache, what happens if someone deletes their browser cache?

^^ Best quote of them all which pretty much sum's up your knowledge of cache/sessions.

CaptainQuack, out.

[IllegalPigeon]

Also, it the answer I got from Google doesnt "completely" agree with you. Did you miss out the part that said it uses memory when reading the data? No, you didn't you just ignored it because you focused solely on the storing of data, whereas I was looking at the bigger picture. You wouldn't store data in a session if you don't intend to read it again.

But that wasn't MY argument. I don't need to learn about sessions, I'm fully aware that reading the data will use a little bit of memory. I don't need to Google how to use sessions or find an answer to prove someone wrong. So yes, I am 100% right and you are 100% wrong with your original argument. I don't know why you're even bothering to say "well sessions use memory when you read them", because in the beginning you said "STORING" data in sessions will use memory.

The memory being used was the for loop that produces 1,000,000 results on the page, not the sessions being stored, so again you're still wrong.

Oh, and of course I wouldn't store data in a session if I wasn't going to use it again. That's neither here nor there, though, the fact of the matter is that storing session data does not use memory. The OP asked about storing a lot of data in a session, you provided an inaccurate answer and I corrected you. Even if he was to store huge data in sessions and call them again later, it STILL doesn't matter because fetching from a session, the database or cache is ALWAYS gonna use memory. So your comment is immediately null.

Also, when we go back to this:

So, what you are saying to me is that if I have 1GB RAM on a server and i try to execute this code:

ob_start();
for($_SESSION['iterator'] = 0; $_SESSION['iterator'] < 3000000000; $_SESSION['iterator']++;){
   echo $_SESSION['iterator']."\r\n";
}
ob_end_flush();

it'll run completely?

just gonna drop this answer here also... http://stackoverflow.com/a/17558888

You clearly think you're right. I provided code that proves otherwise. In the above example, you're again suggesting that running that code which STORES sessions will not run because of the memory usage when in reality it will run if your browser could render 3 billion results (if you're patient enough).

There's no harm in admitting you're wrong. By trying to make out "oh well, I'm only 90% wrong because someone on Stackoverflow said this" is just stupid. Take it on the chin.

Edited August 23, 2015 by IllegalPigeon