Measuring Session Size

[Logu Krishnan]

Hi

I'm trying to profile my application and do sizing of the app.
is there a way to size the session ??

 

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

Hi

I'm trying to profile my application and do sizing of the app.
is there a way to size the session ??

If you are worried that the Session objects might be containing too much
data, then you are putting too much data in them.

The Session objects lives for a very long time, compared to most objects
in a web application. The objects used to create a response lives for a
fraction of a second, while a Session object normally lives for at least
20 minutes. The memory resources that you use when creating a response
is used a very short time, but everything you put in the Session object
will occupy memory for a much longer time, therefore you should not put
large objects in the Session object.

If you put a lot of data in the Session objects, the application gets
sensetive to DoS attacks. It's not hard to fool the application to
create a lot of Session objects, and if the Session objects contain a
lot of data, it can easily fill up the memory of the server.

 

[Logu Krishnan]

Thanks. But, is there a way to measure the amount of memory my session
objects are consuming in the server ?

 

[Peter Bradley]

Hi Göran,

Whilst I agree with your drift, I think it's worth making a couple of
points, even though they don't address the OP's concerns directly. Firstly,
it is the purpose of the Session to be long lived, so it is reasonable to
store in it any objects that need to stay alive while ever the Session stays
alive. These might be quite large contstructs that represent the state of
the objects in the application: but if you need them, you need them. Of
course, the Session object itself will only store references to such
objects, so the Session may not actually be very large. However, the
referenced objects may be taking up a lot of room on the heap. Developers
need to be aware of this, and take steps to destroy objects that they have
finished with.

Secondly, and in passing, virtual memory on modern servers is huge. Objects
on the heap that are only used infrequently will be swapped out if
necessary, so they won't be eating much (as my grandmother used to say).
Getting them back when they are needed might slow an application down
fractionally, but not enough for a user to notice.

Lastly, of course, developers should set the Session timeout value to
something that makes sense for their application. It might be quite a bit
shorter than 20 minutes - or quite a bit longer, of course. Ten minutes
might be adequate for some applicaitons.

Just my 2c. YMMV.


Peter

 

[Guest]

Not sure, but if you are concerned about memory consumption you can get a
simple (not very accurate) "drive by" idea by looking at the VM Size of the
ASP.NET worker process in Task Manager.
Peter

 

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

Hi Göran,

Whilst I agree with your drift, I think it's worth making a couple of
points, even though they don't address the OP's concerns directly. Firstly,
it is the purpose of the Session to be long lived, so it is reasonable to
store in it any objects that need to stay alive while ever the Session stays
alive. These might be quite large contstructs that represent the state of
the objects in the application: but if you need them, you need them.

But there is rarely an absolute need to have things in memory. If the
data comes from a database, you can just store the user id in a session
variable, and fetch whatever you need from the database when you need
it. If the data is any important, you wouldn't want to only keep it in
such a volatile place as a session variable anyway.

A database is of course not as fast as having everything in memory, but
it's scalable. If each user has a large object in a session variable,
you can only serve a specific number of users on the server (free_mem /
object_size), while if you keep the data in the database, the number of
users is practically unlimited.

In reality the optimal balance between performance and scalabilty is
somewhere in the middle. You can't fetch everything from the database as
it's too slow, and you can't keep everything in memory as it runs out.

Of
course, the Session object itself will only store references to such
objects, so the Session may not actually be very large. However, the
referenced objects may be taking up a lot of room on the heap. Developers
need to be aware of this, and take steps to destroy objects that they have
finished with.

Secondly, and in passing, virtual memory on modern servers is huge. Objects
on the heap that are only used infrequently will be swapped out if
necessary, so they won't be eating much (as my grandmother used to say).
Getting them back when they are needed might slow an application down
fractionally, but not enough for a user to notice.

True, but the amount of memory is also a resource that has an absolute
limit. If you are out of memory, the server doesn't serve any more.