Faster: session variables or sql tables ?
-
Anyone have any insight as to what might run faster on a webpage? I'm currently using MySQL tables to store shipping, billing, and order information. Depending on what stage of the transaction process you are in, there are any number of lookups or inserts/updates (typically no more than 2 per stage). I'm curious if just storing everything in a php object and storing it in a session variable would be faster/more efficient. This way, I figure, the queries are minimized (1 or 2 TOTAL), but does the php object add too much weight to the webpage for it to make a noticeable difference?
Anyways.....any thoughts would be great.
Thanks.
-
Whether or not it adds weight, it opens up your data to the end user. This can cause issues if someone decides they want to change some detail that shouldn't be exposed to them in the first place.
I think session information should keep just enough to identify the user, thats all. From the session, you should look up all other information in your database.
Having said that, I don't really know the details behind the session implimentation in PHP. Maybe it stores the session data locally, and just gives the user a (hopefully cryptographically secure) session id as a cookie. If thats the case, go for it. But do some packet sniffing to make sure you're not opening yourself to a script kiddy attack.
-
@ItsAllGeekToMe said:
Anyone have any insight as to what might run faster on a webpage? I'm currently using MySQL tables to store shipping, billing, and order information. Depending on what stage of the transaction process you are in, there are any number of lookups or inserts/updates (typically no more than 2 per stage). I'm curious if just storing everything in a php object and storing it in a session variable would be faster/more efficient. This way, I figure, the queries are minimized (1 or 2 TOTAL), but does the php object add too much weight to the webpage for it to make a noticeable difference?
Anyways.....any thoughts would be great.
Thanks.Stop!!!!
What you are doing is called "premature optimization". If you don't have a performance problem and you aren't doing something seems to be way too slow, ignore performance. Here is the problem you will find for yourself;
Let's say performance actually matters here and the slight difference between the two implementation will actually make a measureable impact on the performance of your site. So, we pick the faster of the two methods (the session variable). Two months later, the site has even more visitors and you find that there aren't any more simple tweaks to help the server keep up with the demand. So, you buy two more servers and use two for application servers with a web server and your PHP app on both and use the third for a database server. BTW, this solution isn't overboard -- two servers will likely cost less and have more of a positive effect than throwing the same amount of time and money at tuning the app. It doesn't take long to burn through $10,000 in development money.
Now, your session based solution (which is faster) now has to be tweaked to work with a server farm. It will either make the migration cost more as you need to tweak the state mechanism to work across multiple servers or force you into a suboptimal situation of making sure that every user is serviced by one and only one server. The faster solution can result in a lower performance end product.
Had you originally chosen the slightly slower, but more scalable, solution of putting state data in a database, then adding more servers would be seamless and would increase performance very easily and cheaply.
The ironic end result of almost any occurrance of "premature optimization" is that any time you go chasing after the last ounce of performance, you end up hurting scalability which hurts performance in the long run. That's why anyone with a few years under their belt will cringe any time a question like this comes up. The best answer really is "shut up and follow the best practices, newbie", just like the gruff senior programmer at work will tell if you work on a good development team.
I wonder if PHP has a solution similar to what ASP.Net has. In ASP.Net, there is a session objct that stores data in memory by default, but can store the data in a database by changing one line of the config file. That way you can change the storage mechanism at any time without changing the app.
-
I'm not entirely sure you've answered my question........but you sure did type a lot. That's all that matters I guess.
Whether or not I implement any sort of change, I was simply curious as to WHAT, if any, performance issues come along with using session variables over sql tables, and vice-versa.
-
What I'm saying is that it is extraordinarily unlikely that you will be able to make something that works better than what PHP has built in. You may be able to make something that's a little faster, but there will most likely be significant drawbacks to the alternative solution.
The reason I didn't answer the question directly was because you asked the wrong question. Rolling your own solutions to common problems in order to increase performance in generally a horrible idea and will eventually land your code on the front page of this site. If you really can do better than PHP's current session handling, the best course of action is to contribute your solution to the PHP project and then use it as a standard feature of PHP.
It's like when someone calls a suicide hotline asking which weapon they should use. The operator isn't going to directly answer the question because any answer is wrong. That's basically why I didn't answer your question.
Try this for more explanation:
-
PHP actually allows you to easily modify sessions to work in whatever way you wish through custom session handlers. PHP defaults to using flat files with serialized session data, but you can extend it to use a database or any other form of data storage. This means that you could rely on sessions to hold all of your persistent data, and simply update them with a new handler if you require more performance or a distributed storage capable system.
Read more here: (Look under 'Custom Session Handlers')
-
@ItsAllGeekToMe said:
I'm not entirely sure you've answered my question........but you sure did type a lot. That's all that matters I guess.
Whether or not I implement any sort of change, I was simply curious as to WHAT, if any, performance issues come along with using session variables over sql tables, and vice-versa.Writing to memory is normally faster than writing to disk. If your platform / implementation stores session info in the memory of the web servers process, then writing to session will be faster.
You may encounter other issues later, i.e. scaling up and and out, network latency, running out of memory on the server, etc. but the simple answer is that its faster to write to memory than it is is to write to disk.
-
@DevilDog74 said:
Writing to memory is normally faster than writing to disk. If your platform / implementation stores session info in the memory of the web servers process, then writing to session will be faster.
You may encounter other issues later, i.e. scaling up and and out, network latency, running out of memory on the server, etc. but the simple answer is that its faster to write to memory than it is is to write to disk.
It's not that simple. Normaly, writing to disk is asynchronous, i.e. your app doesn't have to wait till it's done. If your machine has enough ram, the recently written data is also likely to stay cached in memory, thus reading is fast, too.
On the other hand, if you stuff too much into memory, the machine will start to swap wildly, thus becoming slower...
-
As has been pointed out, there's more than one way to skin the cat.
Storing your state directly in your database is one way of doing things, but is a one-way solution - you can't (easily) swap it out if it proves to be a bottleneck. Session variables stored server side can rely on any number of types of backing store, including but not exclusively: flat files, database, memcached backed, etc etc; I would tend to opt for session variables every time to allow for flexibility should session storage become a problem in the future. It also provides a nice conceptual separation of "transient state" from "real data"...
Simon
-
Well my point of view is that it is not important WHERE you store your session data, but it is much more important WHAT you store in your session!
If you go along and store a whole bunch of stuff in your session you will end up with a poor performance, no matter "where" you store the data. Using a session to cache complex datatypes is not the right way to go. What you can store in a session is for example are strings and IDs like suggested above already. What i would NOT store there is a "table" or something that might be even more complex.
A shopping cart might be a borderline case (ID,Name,Amount,Price) but as soon as you add description I would go to the DB and fetch this information. Also NEVER trust the "price" that you get from the browser... If you do let me know where the shop is and what it is selling ;)
PHP: Sessions - Manual
