Alternative to Sessions

Results 1 to 3 of 3

Thread: Alternative to Sessions

  1. #1
    Scott S Guest

    Default Alternative to Sessions

    Hello everyone,<BR> I have been reading articles on this listserv & various websites about using Database tables as substitute for session variables. I designed a simple system where there are 2 tables, 1 that assigns the GUID & a second that contains the Key/value pairs. The way I have it set up I can pretty much use It just like Sessions but hit the database instead. By doing this I don&#039t have to use the session object at all I do however have to hit the database a lot more (just to retrieve said value pairs) is this a good trade off? Which is worse in terms of scalability, this solution or using the session object? Are there any things that I can do to make the database interaction any faster? (I&#039m using stored procedures & Asp pages) I have Thought about putting it into a VB or VC++ MTS component to get The extra speed from a compiler and the Transaction Server, but the basic frequency of the database hits will be the same. Any thoughts on this? If seeing the code would be helpful I will post it in a future post. <BR><BR>Scott S<BR><BR>

  2. #2
    Mark Guest

    Default RE: Alternative to Sessions

    If your web pages can satisfactorily be run on a single server, then use Session Variables. If your site is a high volume site that will be hit often (like in a "web farm" or clustering configuration), then you should probably use your database method. Using a database to store "state" information is by far the best method if you are using more than one web server to serve a site. This method does carry more overhead (more dtabase connections and queries), however, ot is the only real solotion to multiple web server configurations.

  3. #3
    Ian P. McCullough Guest

    Default RE: Alternative to Sessions

    One thing that you shoudl really bear in mind here though is the limits of scalability of this option. Switching to a databse will stave off the problem for a long time, but what happens when you get even larger. This may not be a problem for you, but here is how it works conceptually:<BR><BR>Say you have a network-hardware-level load balanced web farm of 10 servers and a single databse server for storing client state. What happens when the DB machine can no longer keep up? The web servers sit idle, and users wait (or more likely leave your site for something faster)<BR><BR>So the initial gut response is that you up the number of databse servers. So say you add another DB server. Now you need to load balance between the two. If your traffic is fairly uniform across the web farm (depending on your load balancing setup for incoming client requests) then you can put five servers on one DB and five on the other. Then you have to make sure that the databases are talking to each other to maintain coherent information since each pageview for a given client could come in to either database.<BR><BR>This is a great solution as long your application is heavy on client state reads and not heavy on client state writes. This is because every write prompts a hit on all databases, due to replication. The net result is that if you had one saturated database that you replaced with a pair, with replication, you&#039ve gained nothing if your traffic is 50% writes or more. You can quickly see that this is a dead end strategy. And this is the pitfall to avoid. This is a classic example of when throwing more hardware at a problem mathematically cannot solve it.<BR><BR>Now if you&#039re scaling this large, you&#039ve certainly had a lot of time to sit down and plan things out, but not everyone plans on scaling this large. Often it just sort of happens. Load goes up and you add hardware.<BR><BR>The solution to this problem is really beyond the scope of this response, I simply wanted to point out that this will allow you to scale to a point, but as a scaling strategy, it dies pretty quickly.<BR><BR><BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts