Session State and performance

[lozd]

Hi,

I was wondering if anyone could give me a good guide as to how much can be
stored in the session state before performance is affected?

The app I'm working on is to be hosted on an intranet with in the region of
500 users (not at all times though) but it's intended to be able to be used
accross a variety of environments with different numbers of users and
different grades of servers. As I have no definite info on what the
capabilities of server's powering it are to be I'd like it if someone could
give me a rough idea of when i should think of using something other than
session state.

The idea is too store a database control class/object in the Session state
for each user so that I don't need to reinitialise the object every time a db
access is needed.
The class will likely have several methods. Is this feasible or would it be
a better idea to just recreate the db access object every time?

Thanks in anticipation.

[Nick Malik]

What exactly do you intend to serialize into this database object?

It sounds like you plan to put a connection in there, which won't work.

Using ADO.NET, you get connection pooling, which means that if 10
connections are open to the database, and one app frees their connection,
the next app to call "open" with the same connection settings will get that
connection... a new one does not have to be created. This is all managed
for you.

This makes it fairly easy to manage the connections, because you can pretend
that they are fast to make, and just write your app as though it was opening
the connection directly.

Also, if there is lookup data that you want all users of your app to use,
you can create some singleton objects in the ASP.NET side to hold the data
from the database. That way, only the first user to look up this static
data would pay the price of getting it and storing it in memory for all
other users to use.

HTH,
--- Nick

"lozd" <lo**@discussio ns.microsoft.co m> wrote in message
news:59******** *************** ***********@mic rosoft.com...

Hi,

I was wondering if anyone could give me a good guide as to how much can be stored in the session state before performance is affected?

The app I'm working on is to be hosted on an intranet with in the region of 500 users (not at all times though) but it's intended to be able to be used accross a variety of environments with different numbers of users and
different grades of servers. As I have no definite info on what the
capabilities of server's powering it are to be I'd like it if someone could give me a rough idea of when i should think of using something other than
session state.

The idea is too store a database control class/object in the Session state
for each user so that I don't need to reinitialise the object every time a db access is needed.
The class will likely have several methods. Is this feasible or would it be a better idea to just recreate the db access object every time?

Thanks in anticipation.

[lozd]

Thanks for the quick reply.

You've pretty much hit the nail on the head. I was intending to put the
connection in Session state (along with a few supporting methods for using
it) but from what you've told me it's not necessary.

I do have one other query if you don't mind though just to make sure I've
got your answer clear in my head (Sorry if this is a bit obvious).
If I use the connection objects "Close" method in the app - the actual
connection is still maintained in the connection pool. Is this the situation?

"Nick Malik" wrote:

What exactly do you intend to serialize into this database object?

It sounds like you plan to put a connection in there, which won't work.

Using ADO.NET, you get connection pooling, which means that if 10
connections are open to the database, and one app frees their connection,
the next app to call "open" with the same connection settings will get that
connection... a new one does not have to be created. This is all managed
for you.

This makes it fairly easy to manage the connections, because you can pretend
that they are fast to make, and just write your app as though it was opening
the connection directly.

Also, if there is lookup data that you want all users of your app to use,
you can create some singleton objects in the ASP.NET side to hold the data
from the database. That way, only the first user to look up this static
data would pay the price of getting it and storing it in memory for all
other users to use.

HTH,
--- Nick

"lozd" <lo**@discussio ns.microsoft.co m> wrote in message
news:59******** *************** ***********@mic rosoft.com...

Hi,

I was wondering if anyone could give me a good guide as to how much can

be

stored in the session state before performance is affected?

The app I'm working on is to be hosted on an intranet with in the region

of

500 users (not at all times though) but it's intended to be able to be

used

accross a variety of environments with different numbers of users and
different grades of servers. As I have no definite info on what the
capabilities of server's powering it are to be I'd like it if someone

could

give me a rough idea of when i should think of using something other than
session state.

The idea is too store a database control class/object in the Session state
for each user so that I don't need to reinitialise the object every time a

db

access is needed.
The class will likely have several methods. Is this feasible or would it

be

a better idea to just recreate the db access object every time?

Thanks in anticipation.

[Nick Malik]

If I use the connection objects "Close" method in the app - the actual
connection is still maintained in the connection pool. Is this the situation?

Yes, this is the case.

No need to manage it yourself.

--- Nick