[SOLVED] Will Having alot of Session Variables Slow Down Your Website?

[limitphp]

Will Having alot of Session Variables Slow Down Your Website?

By alot I mean like 9 or 10.....

 

or can the server handle that no problem.....and I shouldn't worry about that....

 

things like page numbers for pagination and other simple variables....

[kenrbnsn]

Nine or ten is not a lot of session variables.

 

Don't worry about it.

 

Ken

[.josh]

session data is serialized and stored in a flatfile and retrieved upon demand.  Using them all at once (like in a loop or function that walks an array or whatever) would add up (as ken pointed out, 9 or 10 does not constitute 'adding up' unless the data is extremely large.  Simple vars like pagination page number is nowhere near breaking point), but using them individually would not.

[limitphp]

session data is serialized and stored in a flatfile and retrieved upon demand.  Using them all at once (like in a loop or function that walks an array or whatever) would add up (as ken pointed out, 9 or 10 does not constitute 'adding up' unless the data is extremely large.  Simple vars like pagination page number is nowhere near breaking point), but using them individually would not.

 

thanks guys....

Actually, crayon, I was just reading your pagination tutorial...and I was thinking, if I store the page number in a session variable, can I assume its alot more secure, and not have to do all the isnumeric checking and greater than totalpages checking?

[premiso]

session data is serialized and stored in a flatfile and retrieved upon demand.  Using them all at once (like in a loop or function that walks an array or whatever) would add up (as ken pointed out, 9 or 10 does not constitute 'adding up' unless the data is extremely large.  Simple vars like pagination page number is nowhere near breaking point), but using them individually would not.

 

thanks guys....

Actually, crayon, I was just reading your pagination tutorial...and I was thinking, if I store the page number in a session variable, can I assume its alot more secure, and not have to do all the isnumeric checking and greater than totalpages checking?

 

But if you want it to be viewable to indexing bots, it needs to be apart of the url or else they will never be able to goto the next page.

[limitphp]

But if you want it to be viewable to indexing bots, it needs to be apart of the url or else they will never be able to goto the next page.

 

I see...thank you.

[.josh]

Well...if we were to compare session variables to GET variables in a general sense, using a session variable vs. a raw GET variable (pre-validated) would be more secure, yes. 

 

But its not necessarily more efficient.  For starters, you'd just replace validation code with maintenance code,  since the value would persist (as in, writing code to update the session variable).

 

Also, you have to consider the physics of pagination.  The point is to click a link, and each link causes the content to be altered.  The only way your script would know that one link was clicked instead of another, is by attaching a value to it, which would be using GET, anyways.  Unless you were to have the links pointing to different pages like 1.php 2.php 3.php but even then, someone can just directly type that into your url, and you'd have to be checking for that somewhere else anyways (be it custom 404 pages, mod rewrites, etc...). 

 

You could use an AJAX or FLASH interface or even make a whole bunch of mini-forms with just submit buttons, but once again, you should be validating the incoming info anyways, as even POSTed info can be altered pretty easily. 

 

Point is, session vars are generally more secure than raw GET vars in a general sense, but you can't really use just session vars with pagination, so it's kind of moot.

[limitphp]

Well...if we were to compare session variables to GET variables in a general sense, using a session variable vs. a raw GET variable (pre-validated) would be more secure, yes. 

 

But its not necessarily more efficient.  For starters, you'd just replace validation code with maintenance code,  since the value would persist (as in, writing code to update the session variable).

 

Also, you have to consider the physics of pagination.  The point is to click a link, and each link causes the content to be altered.  The only way your script would know that one link was clicked instead of another, is by attaching a value to it, which would be using GET, anyways.  Unless you were to have the links pointing to different pages like 1.php 2.php 3.php but even then, someone can just directly type that into your url, and you'd have to be checking for that somewhere else anyways (be it custom 404 pages, mod rewrites, etc...). 

 

You could use an AJAX or FLASH interface or even make a whole bunch of mini-forms with just submit buttons, but once again, you should be validating the incoming info anyways, as even POSTed info can be altered pretty easily. 

 

Point is, session vars are generally more secure than raw GET vars in a general sense, but you can't really use just session vars with pagination, so it's kind of moot.

 

I see.  Yeah, I'm going to use the querystring and do a url rewrite.

Thanks.

[.josh]

Well see, that's the point.  You're passing vars through the url anyway, so they have to be validated anyway, so putting it into a session var is superfluous.