|
Session veriables or SQL storage (best solution)?
QUESTION:Session veriables or SQL storage (best solution)?
I have a web application that will handle anywhere for 50 to 175 users at one
time but will likely have a user base in the 100s. This application contains
a GUI interface for the every day user and web services that can access the
GUI modules for 3rd party applications needing to get shared data
In the initial design plan, the idea was presented to retrieve the data for
the users dashboard and hold that data in session, only connecting to SQL
for the initial load and any update and delete. This way with each post back,
there us no need to connect to SQL to reload the data on a change. This is
b/c the SQL server is used by several in house applications not related to
this one and we had issues in the past of SQL server getting bogged down. So
the idea is to limit request to SQL with this application as needed. Its
cheaper for use to setup a dedicated web server then it is SQL server since
we have so many database that need to cross communicate, and SQL server
linking is just too slow and unreliable.
What is the trade offs of storing the session data in SQL? Even though it
still hitting SQL, I figure its still more efficient then executing the
entire query for the data. I know it would make it more scalable, but would
we not just end up back with SQL server getting bogged down again?
Now I realize holding entire dataset in memory is a big deal, in fact there
a 8 datasets per user. These datasets are quite small, anywhere from 1
datarow to up to 10 datarows.
The application is fast, but hasnt been tested user say 50 simultaneous
users. Would you go with a RAM packed out web server dedicated to the app, or
store sessions in SQL on server that cannot be dedicated?
ANSWER: There is a third option, which is
http://msdn2.microsoft.com/en-us/library/system.weakreference.aspx
The WeakReference class. You can weakreference object(s) in the Session,
and have "smart code" that figure out whether or not the data is cached, but
your have a work around if server strain is high.
Fourth option:
Don't use "bulky" dataset objects. Write custom objects/custom collections
to keep your data. They will probably have to be Serializable, but their
footprint ends up being smaller than a DataSet usually.
Fifth option. There are third party session state applications.
|
|
|
|
