Is this so wrong?

[Ethan V]

To optimize performance, I plan on putting any useful information for a user
in a session cache/variable. Our web server will have 2GB of memory to start
out with.

Since I will be very liberal in the amount of data I'll put in the session,
I know that will use lots of memory resource. But my plan is to monitor the
web server activity, and when traffic ramping up, all I need to do is add
another 2GB, then another 2GB until I max out memory allowed on the box.
When I can't add anymore memory, I will add another box to serve the site.

Is my plan so simplistic, and so wrong? Please share with me your
experiences and your thoughts. Thanks so much in advance.

 

[Mark Rae]

To optimize performance, I plan on putting any useful information for a
user in a session cache/variable. Our web server will have 2GB of memory
to start out with.

Since I will be very liberal in the amount of data I'll put in the
session, I know that will use lots of memory resource. But my plan is to
monitor the web server activity, and when traffic ramping up, all I need
to do is add another 2GB, then another 2GB until I max out memory allowed
on the box. When I can't add anymore memory, I will add another box to
serve the site.

Is my plan so simplistic, and so wrong? Please share with me your
experiences and your thoughts. Thanks so much in advance.

Caching user data in Session is a great idea - but only if you need to...
There's nothing particularly "right" or "wrong" about doing this - the
Session object is there to be used after all...

Only you can decide how much or how little metadata to store...

E.g. if you have lots and lots of concurrent users, anything you can do to
minimise repetitive database querying is probably a good idea.

However, if you're initial premise is that all you have to do is throw more
hardware resources at your site and everything will be well, you really
should take a step back and try to design your site properly.

 

[Patrice]

Just make sure to see what you buy for this memory comsumption i.e. make
sure you put on cache something that is frequently used (things used by all
users rather than by one user would be likely the first candidate etc
etc...). Also before caching something you may want to check if the query
could be improved etc...

 

[Andrew Morton]

To optimize performance, I plan on putting any useful information for
a user in a session cache/variable. Our web server will have 2GB of
memory to start out with.

You might want to set the session cache to use the aspnet_state service
so that if you update the site the current sessions don't lose their
states (or when the worker process gets recycled). Or even use SQL
server to hold the session data, which can (as far as I read) keep data
even over a machine reboot.

Andrew

 

[bruce barker \(sqlwork.com\)]

couple issues:

1) hopefully your 64 bit.
2) you will have to bump up the memory limits, or your asp.net app will
recycle (which dumps all session data).
3) you can not just add another box, as they will not share session data.
you need to use an out of proc session manager for a web farm.
4) session memory is only released at session timeout (20 minutes of no
activity), so you may have more sessions than you think.

-- bruce (sqlwork.com)

 

[Jon Paal]

I think you need to clarify which you are going to be using (?)

I believe it's either session or cache. I never heard of a "session cache/variable".

I believe cache will self clear pending memory limits.

 

[V]

Hi Ethan,

Seems like a workable solution.

Normally, where I work, we tend to use the Cache object much mroe than
the Session Object.

Also, Cache is faster than Session.

However, I don't think that the Cache object approach will work in a
server farm scenario (i am not sure whether it will be shared between
different instances of the site).

Also, consider proper usage of the Session Object. I have come across
developers storing connection objects in a Session Object. Now that
would be wrong because this causes the IIS to block a connection in the
connection pool.

So a session object misused can really slow down the site, even without
using too much memory.

Aside from that I think your idea would work.

Hope that helped.
- Vaibhav

 

[Joerg Jooss]

Thus wrote Ethan,

To optimize performance, I plan on putting any useful information for
a user in a session cache/variable. Our web server will have 2GB of
memory to start out with.

Since I will be very liberal in the amount of data I'll put in the
session, I know that will use lots of memory resource. But my plan is
to monitor the web server activity, and when traffic ramping up, all I
need to do is add another 2GB, then another 2GB until I max out memory
allowed on the box. When I can't add anymore memory, I will add
another box to serve the site.

Is my plan so simplistic, and so wrong? Please share with me your
experiences and your thoughts. Thanks so much in advance.

Save for the more technical issues mentioned, relying heavily on session
state may create hidden dependencies if not managed and developed carefully.
These dependencies can be quite subtle -- a page blindly relies on the existence
of a given session state, but because of the navigation path to that page
the session attributes always exist und thus the page works fine, until...
well, the day that you change the navigation path to that page and find that,
all of a sudden, it breaks due to some missing session state.

Cheers,

 

[Ethan V]

Thank you so much everyone for your advices. They clear things up a lot for
me.

 

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Another thing to consider is security. If you put a lot of data in
session variables, the server becomes vulnerable to DoS attacks. A
malicious user could make a lot of requests to the server, each creating
a new session. This would fill up the memory of the server very quickly.

 

[Pandurang Nayak]

What is vitally important is also to do proper capacity planning. Find
out the number of users you have, the data size of the variables you
plan to cache, etc.

You should look at caching frameworks (ASP.NET 2.0 has a lovely caching
framework) which will allow you to expire data that is not frequently
accessed, data that has changed in the backend, etc.

You should also take careful consideration of the fact that you might
move into a web farm scenario at a later point. How will sessions be
managed then - because there is no way of synchronizing sessions across
servers unless you use an out-of-proc storage mechanism. Needless to
say, that hampers performance. Even if it is that tiny wee bit.

So have all your considerations carefully planned because it might be
too much rework to roll back to a different solution at a later point.

Also check out the Microsoft Patterns and Practices caching guidelines
and the EL Caching block design. I am sure you will soon realize that
it is a little more complicated than it appears.