$_SESSION VS MYSQL For Ajax updates

[Monkuar]

Let's say I grab all the user's information from the users table.

 

It's stored into a variable as an array: $pun_user.

 

Now, to get access this user data, it selects all the data each refresh and sets it to $pun_user for extraction later.

 

My idea:

 

Create a $_SESSION['user_id'] = $pun_user['user_id']

 

And then when using updating stuff via ajax requests, I can just do SELECT blah from users where where user_id = $_SESSION['user_id']

 

instead of: calling the main query to enter all the data into $pun_user, then do that query AGAIN and do SELECT blah from users where user_id = $pun_user['user_id']

 

Is the $_SESSION way going to take a performance hit on the server? Or is the MYSQL way a more detrimental approach? Which way is faster, and less intrusive on the server?

Edited January 23, 2015 by Monkuar

[requinix]

Most sites store things like the user ID in the session. It's fine. Mostly you'd only need to worry about storing data that could change, but a user ID wouldn't (shouldn't).

[Monkuar]

Most sites store things like the user ID in the session. It's fine. Mostly you'd only need to worry about storing data that could change, but a user ID wouldn't (shouldn't).

But how is updating session variables as compared to updating a field in MYSQL? (Same for reading and writing), which way is faster, and has better performance?

 

It's dependent on how the data is being used and what it is being stored correct?

 

When you're updating a Session Variable is it essentially doing a fwrite to a file inside the tmp folder correct?

 

..And when you're calling a session variable, it's essentially being read (fopen) function per request right?

Edited January 23, 2015 by Monkuar

[scootstah]

instead of: calling the main query to enter all the data into $pun_user, then do that query AGAIN and do SELECT blah from users where user_id = $pun_user['user_id']

Why do you need to run the query again if you already have the data?

 

Also, how are you keeping a user logged in if you're not already using sessions? If you're already using sessions, then you're already reading (and maybe writing) them for every request anyway.

 

In any case, reading/writing sessions and/or executing one MySQL query per request is absolutely not a problem.

[Monkuar]

Why do you need to run the query again if you already have the data?

 

Also, how are you keeping a user logged in if you're not already using sessions? If you're already using sessions, then you're already reading (and maybe writing) them for every request anyway.

 

In any case, reading/writing sessions and/or executing one MySQL query per request is absolutely not a problem.

From the cookies. (fluxBB) forum software. It checks the users cookie per each request to the users table to authenticate.

 

My question is why do I need to do this PER each request when I can just store the user id in a session and use that to stuff (INSERT, UPDATE) for that user? (For ajax updates)

Edited January 23, 2015 by Monkuar

[scootstah]

So it's reading a cookie and performing an authentication check on every AJAX request? That's kind of silly, AJAX is not stateless.

 

To answer your question, you do not need to do that on every request. Once the user is authenticated, the session should reflect that on subsequent page loads.

[Monkuar]

So it's reading a cookie and performing an authentication check on every AJAX request? That's kind of silly, AJAX is not stateless.

 

To answer your question, you do not need to do that on every request. Once the user is authenticated, the session should reflect that on subsequent page loads.

No, not on every ajax request but on each manual page refresh. That's where I'm getting it! I don't want it to do that per ajax request, but to just use the $_SESSION['user_id'] instead, will that be okay? How do I go about the session expiration and stuff? What if the session expires, and they call the ajax request....

 

It won't expire if I set the $_SESSION['user_id'] to the users real id per page refresh, but I don't want to do that per refresh if that helps

Edited January 23, 2015 by Monkuar

[scootstah]

Yes, once the $_SESSION is populated it will live for the life of the session (or until PHP expires it). So, you're free to rely on it through AJAX requests, assuming that the user has been authenticated prior.

 

To deal with session expiry, your server will have to return an error that your javascript app can capture and handle. You will probably have to have some logic to queue anymore requests, while simultaneously calling an endpoint to re-authenticate the user, and finally executing all of the queued requests. Or, if you don't care about queued requests, you can just redirect the user and make them re-do the action.

[Monkuar]

Yes, once the $_SESSION is populated it will live for the life of the session (or until PHP expires it). So, you're free to rely on it through AJAX requests, assuming that the user has been authenticated prior.

 

To deal with session expiry, your server will have to return an error that your javascript app can capture and handle. You will probably have to have some logic to queue anymore requests, while simultaneously calling an endpoint to re-authenticate the user, and finally executing all of the queued requests. Or, if you don't care about queued requests, you can just redirect the user and make them re-do the action.

Yeah, the user has been authenticated. But, the user an option to be 'logged in forever'. This means the system will not delete the users cookies (essentially) so whenever that user logs in, he will stay authenticated forever if he pressed that button. Then upon any refresh, the system will authenticate him.

 

 

So I can just check if the user submitted an ajax request, and if the user is not logged in, just do a simple refresh, or check if he has the correct cookies and send out the data right?

 

So you're saying have a fallback method when the user checks it via ajax request, if his session has expired. (How long do PHP's sessions last) Edit: Looks like I checked here: http://stackoverflow.com/questions/8311320/how-to-change-the-session-timeout-in-php and they say around 1 hour. I could edit that and make it longer though, but wouldn't that be a toll on the server?

 

In any event. I'm just worried about these damn sessions because I heard there is a lot of fwrite and fopening functions happening in the /tmp/folder when updating/reading the sessions as compared to just selecting the data from MYSQL. I am very, VERY on edge and OCD about it.

 

I have rate limiting with iptables and nginx, all set up but I'm just feeling a weird vibe with sessions.

Edited January 23, 2015 by Monkuar

[scootstah]

If it makes you feel better, you can use session handlers to read/write sessions from wherever you want. You can write to the database, write to a cache store, whatever you want.

 

However, before you go to all that work, have you actually profiled your application? Have you seen data that suggests that your page is slow because of iowait? If not you're jumping the gun a bit. Don't solve problems that don't exist yet.