session variables vs cookies

[Jeremy21b]

We're currently redesigning our website. As it is fairly high traffic, we need to be as efficient as possible. When a person searches for a product, I want to save this search. I'm not sure whether it would be better to use cookies or session variables. My thinking was that using session variables might be a waste of memory on the server. Is this correct? Would there be any downsides to using cookies instead?

Also on the topic of variables, should I be wary of putting too much information into application variables? Currently we have all of our product brand names in application variable arrays. I was considering putting all product model names (about 700 names) in application variable arrays as well. This would eliminate a lot of extra SQL queries. Would this be more efficient?

Thanks.

 

[DreXor]

in the past with search statistics etc, i'd write them to the db, simple little ...

select from table where search like blah
if not rs.eof then
update table counter = counter+1
else
insert table(searchitem,counter) values(blah,1)
end if

then you can use this little 2-3 field table for a lot of statistics, even add a relational table to log, logged in user, ips, record what page the search was made from etc...




DreX
aKa - Robert

 

[Jeremy21b]

No thanks. Our SQL server is overused and is slowing down our entire website. We are not saving their search for statistics, it's so their search is in tact when they return to the search page. We need to be more efficient, and adding more SQL queries is not more efficient. Thanks anyway.

Can anyone else help?

 

[TJRTech]

Cookies or session vars I think it won't make a big difference in server. People think that there is something mythical and stateful about an IIS webserver, that it keeps a lot of memory around for stuff in session. It doesn't. Session variables are passed back and forth between the client browser and the website as part of the HTTP header. So, you save I/O if you reduce the use of session vars, but not memory on the server. Also, cookies are stored locally and they get sent back and forth the same way.

As for your 700 product names in application variables instead of the database because your DB is bogging down, I would say fix your DB. Something as critical as getting a list of your product numbers, especially if something that is performed early on in your user's web session, and often if you have lots of users, should be something that your DB performs in lightning speed...especially considering caching of queries, resultsets that intrinsically happens in a DB like SQL Server.

TR

 

[snowboardr]

If SQL server is slowing down because of 700 names, you really need to think about switching to MySQL. That is sad that it would show such slow performance with a small amount of records.

www.vzio.com
ASP WEB DEVELOPMENT

 

[Tarwn]

Actually, Session variables are NOT passed between the client browser and the website. If that were the case we wouldn't have session variables, just cookies.

Cookies are stored client-side and passed back and forth in the headers. Unless you have a great deal of information in the cookies your not going to see any difference in communications time, especially with the higher speed connections available these days.

Session variables ARE stored in memory on the server. The SessionID that is generated for each visitor is sent to the client in a cookie, but that ID is used as a lookup value to key to the session variables stored on the server. While memory usage may not be that high for single users, it can become a problem if your storing large numbers of objects. You can estimate the amount of memory usage simply by looking at how many unique visitors you have over a 20 minute period. If it's a lot then you don't want to use Session Variables for more then small variables (numbers, strings, very small arrays, etc). The other problem with Session variables is that by putting objects in them you can cause more probklems due to the threading models of those objects and IIS in general.

Using an Application variable to store an array of your product names is what Application variables were made for. While you will b using some resources to keep that array in memory, if your getting many hits/minute then compare storing that one array to: Creating a database connection, Executing an SQL query, communications time, internal building of recordset (which will require more memory then the 700-element array) - now multiply by hits/minute.
While the Application variable will hold on to that memory until the next reboot, even in an absolute best case scenario where a recordset with the same data only needed the same memory (not posible by the way, recordset will always need more) the application variable will be more efficient because there will not be one recordset, but one for every user, meaning more memory being allocated/deallocated, more threads in use, more threads waiting to talk to the database, etc.

-T

_{01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111}
Help, the rampaging, spear-waving, rabid network gnomes are after me!

 

[Tarwn]

Argh missed the database posts. I agree that queries for 700 records should not slow down your system much (though I pointed out that Applicaiton variables may be better in my previous post). But then again it may depend on how many other functions your database is currently responsible for and how much data is in it. Personally I don't think SQL Server should noticeably slow down for a 700 record query unless it is incredibly overloaded or the database design is less then normalized.
You may want to look into building stored procedures for your other database operations to add as little load to that server as possible (stored procedures are more efficient then blind SQL queries since the database can examine them ahead of time and compile them).
I would also look into possible design issues in both the database and queries going to the database. For instance, changing a bunch of commonly used SQL statements from using Left Crosses (comma delimited list of tables) to Inner Joins will help the database work more efficienctly becaue the inner join will only join records that are related rather then doing a simple cross between all records in all tables (either way a temporary table is built for the FROM sttaement, then it is whittled down by the WHERE statement). Also make sure you specify fields in your select statements rather than SELECT *'s. A Select * makes the database do more work because it first has to go out and do a pre-query to find the fieldnames that will results from any crosses or joins in your FROM statement. This basically means that for any query containing a star your database is executing two queries instead of one.

MySQL is a good system for a web driven database as it is fastr on SELECT statements, which are used a lot more in data-driven websites then UPDATEs and INSERTs. But, I am not sure a database changeover is necessary in this case if the database is noticeably slowing down, I would tend to think some redesign may be in order.

_{01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111}
Help, the rampaging, spear-waving, rabid network gnomes are after me!

 

[TJRTech]

Right, sessions are stored on the server, I do know how this stuff works, just misspoke. I wouldn't store anything in session that isn't truly transient in nature. Something like the options used to fill out a search form are good for session, but not for a cookie, unless of course I wanted to keep those options from one execution of the web app to the next (I find these cases rare).

As for MySQL being faster than SQL, I would have to see the benchmarks. Is your web server and your DB server on the same box?

If they were on the same box, then the query AND the db connection would be cached in memory and the difference between getting a "very often used resultset" from the DB or from app vars is negligible.


TR

 

[snowboardr]

MySQL Benchmarks:

http://dev.mysql.com/tech-resources/benchmarks/

I saw better benchmarks on MySQL before, but can't seem to locate them at this second, they narrowed down each SQL statment vs each database. If I locate it i'll post it.

www.vzio.com
ASP WEB DEVELOPMENT