• 1 Vote(s) - 4 Average
  • 1
  • 2
  • 3
  • 4
  • 5
How much is too much session data?

#1
I am just doing a structural design for a new site and was wondering what people thought about session data.

Normally I might use it for user status, a couple of nav options, a display option or two etc.

But, I just thought of a snazzy way of achieving the sites goal for visitors but it means loading a fair amount of info into the session data.

I am guessing that it will involve about twenty session variables. Each usually strings or very small arrays of a few variables each. Do you think that is ok if sessions are table based. I know the blob field is pretty big (64kb I believe), but are there any other considerations before I start packing it out that I have overlooked?

All help or advice warmly welcomed.

Best wishes,

Paul.
Reply

#2
Hi Paul, I use database sessions since a few years, with MySQL, it's working 100% fine and fast.

I use a mediumblob datatype for the data column and my application saves a lot of data, usually my own objects like business instances (Customers, Orders, Users, etc) and other types of objects like search filters.

My session table has ~4K records right now and its size about 43 MB, looking at phpmyadmin. The blob field usually stays between a few bytes and 16 KB max.
Reply

#3
We have audit data which is like session data (we track everything from an admin's tool so we can track whatever we need to) - and our largest table is over 50 million records and 20 gigs. (we also have a fair amount of iron behind that)
Reply

#4
(07-07-2017, 11:18 AM)fmertins Wrote: I use a mediumblob datatype for the data column and my application saves a lot of data, usually my own objects like business instances (Customers, Orders, Users, etc) and other types of objects like search filters.
That is a good idea to change it to a medium blob type. Glad to hear what I am planning will work from a practical level.

(07-07-2017, 11:41 AM)Kaosweaver Wrote: We have audit data which is like session data (we track everything from an admin's tool so we can track whatever we need to) - and our largest table is over 50 million records and 20 gigs. (we also have a fair amount of iron behind that)
Firstly, that sounds like an amazing site. Congrats on such a successful implementation. I really like the idea of your audit data. I thought I could just interrogate the session blob but actually that disappears pretty promptly so I will give some thought to something like your audit data.

Could you tell me a little bit more about how it works, or how you implemented it. Just a broad overview of course. Have you replaced the sessions with your own? Not sure I am keen on trying that, or do you just use additional tables to record data as and when it is written to sessions, so you can analyse it later (or similar). It seems like a great idea. I was thinking about logging page views of site visitors to start tracking where they go and what they do. I know there are packages that do similar but they always seem to have lots of bloat I don't need, or do things in a way I do not want. So was considering building something to work the way I wanted.

Best wishes,

Paul.
Reply

#5
Just remember that older sites have a limit of around 4K for cookies.

If you use a database there should be no problems.
What did you Try? What did you Get? What did you Expect?

Joined the CodeIgniter Community in 2009.          ( Skype: insitfx )
Reply

#6
I try to put as little as possible in the session. In most cases, all I have is an authentication identifier. Everything else is in the database, so why store it in the session? Yes, yes, there are obviously reasons to have things that persist between page loads, but for those I mostly use cookies. I like to keep the session clean. That's just my preference.
Reply

#7
(07-07-2017, 06:18 PM)skunkbad Wrote: I try to put as little as possible in the session. In most cases, all I have is an authentication identifier. Everything else is in the database, so why store it in the session? Yes, yes, there are obviously reasons to have things that persist between page loads, but for those I mostly use cookies. I like to keep the session clean. That's just my preference.

For instance, suppose I am not logged in, and I add an item to my basket. Where does that information go? I have no user id to associate the item with the user, so I have to add it to the session. If they then log in, I transfer the basket to an order table that is linked to the user.

Another example might be that the visitor clicks the 'collapse menu' option. Again, that setting has to go into the session does it not, so on the next page load the menu will load up in a collapsed state.

Another example might be a product comparison. A non-logged in visitor adds two items to the comparison list or a favourites list. This info needs to be in the session data. Or the selection of dark text/ light background or light text/dark background layouts etc. All those UI choices need to be in the session surely?

I did for a while have two columns in my tables, user_id and session_id, so that a non logged in user had a user_id of 0. But the tables filled up with junk data so fast that I really felt uncomfortable with it. It seemed messy. At the same time, having to use either table data or session data depending on the user status, also becomes very messy.

Is there something I am missing? Or, because a user can be logged in and identified, or not, is there always going to be two parallel systems running, one based on user_id and the other based on session_id.

I do like the idea of keeping session data clean, but if I do not load up the session data with information, I find that the cost of doing this is very messy functions. If I use session data for logged in users as well as visitors, everything suddenly feels cleaner. So the choice seems to be messy session data or messy functions.

Hmmm. Really not sure now.

Best wishes,

Paul
Reply

#8
(07-08-2017, 03:21 AM)PaulD Wrote:
(07-07-2017, 06:18 PM)skunkbad Wrote: I try to put as little as possible in the session. In most cases, all I have is an authentication identifier. Everything else is in the database, so why store it in the session? Yes, yes, there are obviously reasons to have things that persist between page loads, but for those I mostly use cookies. I like to keep the session clean. That's just my preference.

For instance, suppose I am not logged in, and I add an item to my basket. Where does that information go? I have no user id to associate the item with the user, so I have to add it to the session. If they then log in, I transfer the basket to an order table that is linked to the user.

Another example might be that the visitor clicks the 'collapse menu' option. Again, that setting has to go into the session does it not, so on the next page load the menu will load up in a collapsed state.

Another example might be a product comparison. A non-logged in visitor adds two items to the comparison list or a favourites list. This info needs to be in the session data. Or the selection of dark text/ light background or light text/dark background layouts etc. All those UI choices need to be in the session surely?

I did for a while have two columns in my tables, user_id and session_id, so that a non logged in user had a user_id of 0. But the tables filled up with junk data so fast that I really felt uncomfortable with it. It seemed messy. At the same time, having to use either table data or session data depending on the user status, also becomes very messy.

Is there something I am missing? Or, because a user can be logged in and identified, or not, is there always going to be two parallel systems running, one based on user_id and the other based on session_id.

I do like the idea of keeping session data clean, but if I do not load up the session data with information, I find that the cost of doing this is very messy functions. If I use session data for logged in users as well as visitors, everything suddenly feels cleaner. So the choice seems to be messy session data or messy functions.

Hmmm. Really not sure now.

Best wishes,

Paul


I did say that there were reasons to have things persist between page loads, and you've pointed out some examples.

I did say that I like to use cookies too.

I'll admit, I mostly work on one website, and 90% of it is not visible to the public. Out of:
  • 95 controllers
  • 65 models
  • 140 tables in the database
  • 42 libraries
I need to put nothing in the session except for my auth identifier. We are using about 5 cookies.

It's just my opinion that session data storage is overused by PHP beginners, and sometimes those habits are long lasting.
Reply

#9
@PaulD, for your shopping cart example I find it very usefull to store the information in a seperate table. In here I link a session id to product id's. That way you still have the information when a clients session has expired. You can perform some analasys about what producs are placed in the cart but never get ordered for example.
Reply

#10
Generally I try to avoid using session data except where necessary;

1. Session identifier
2. Flash data
3. Temporary data

Shopping carts are an interesting example of where storing them in the DB can be preferred. If you generate a fingerprint for an anonymous user and store their cart using that fingerprint (or their ID if they're signed in), if they return to your site you can preload their cart with the items they had selected. You can also query your temp carts to see what items people are adding and abandoning.

You could store that in cookies but personally I've found them unreliable so I avoid using them. And you can't query abandonment.
Reply


Digg   Delicious   Reddit   Facebook   Twitter   StumbleUpon  


Users browsing this thread:
1 Guest(s)


  Theme © 2014 iAndrew  
Powered By MyBB, © 2002-2017 MyBB Group.