Session Variables Question

Can somebody tell me how many Session variables would be considered
exessive, and when they start really affect the server speed.
For example on 20-30 asp pages I need to use about 200-300 session variables
and 5 arrays by 1000 elements 50 characters long each.
Let say having 300 users using those pages at the same time.
Server is not the fastest one, just CPU 2.40GHz.

So question is as a user am I going to feel a difference in speed between if
I am the only user,
and if all 300 users are online at the same time.

And if using of so many session variables not a good idea, so what's an
alternative?

Regards,
Michael

Anthony
Mon Sep 11 07:13:42 CDT 2006


"Michaelk" <michaelk@gizmowireless.com> wrote in message
news:OuiESSK1GHA.4972@TK2MSFTNGP03.phx.gbl...
> Can somebody tell me how many Session variables would be considered
> exessive, and when they start really affect the server speed.
> For example on 20-30 asp pages I need to use about 200-300 session
variables
> and 5 arrays by 1000 elements 50 characters long each.
> Let say having 300 users using those pages at the same time.
> Server is not the fastest one, just CPU 2.40GHz.
>
> So question is as a user am I going to feel a difference in speed between
if
> I am the only user,
> and if all 300 users are online at the same time.
>

You didn't specify how much memory you have but a conserative estimate would
put the memory requirement at 300MB for the data described

The answer really depends not on how many users you have but how many
requests per second will be processed and how much of this session data is
needed by those requests. A key problem area would be the arrays which need
to be copied into the request execution context and if modified copied back
to the session object. Each represents the copying of 100Kbytes and the
allocation/deallocation 5000 strings.

If you only get one request per second and only a sub-set of the arrays and
other variables are used per request you could probably get away with this.

> And if using of so many session variables not a good idea, so what's an
> alternative?
>

An alternative is to use a Database. Store useful groups of values in a set
of tables and of course each array in tables, each table should contain a
key field that links the data to your session. You can then just store a
few highly active session variables in the session object and store in the
session object a key that represents your sessions data in the DB. You will
need some housekeeping to eliminate data from sessions that are no longer
active.


> Regards,
> Michael
>
>

Michaelk
Mon Sep 11 13:44:27 CDT 2006

Thanks Antony.
Actually I have all this data in the SQL server right now, and a few session
variables.
Just was thinking if it makes a sense to trade all those database
connections and
browsing recordsets to load the data ones in the session variables and have
it
all handy right here in the session, specially arrays.

Regards,
Michael

"Anthony Jones" <Ant@yadayadayada.com> wrote in message
news:ORRX6uZ1GHA.1336@TK2MSFTNGP03.phx.gbl...
>
> "Michaelk" <michaelk@gizmowireless.com> wrote in message
> news:OuiESSK1GHA.4972@TK2MSFTNGP03.phx.gbl...
>> Can somebody tell me how many Session variables would be considered
>> exessive, and when they start really affect the server speed.
>> For example on 20-30 asp pages I need to use about 200-300 session
> variables
>> and 5 arrays by 1000 elements 50 characters long each.
>> Let say having 300 users using those pages at the same time.
>> Server is not the fastest one, just CPU 2.40GHz.
>>
>> So question is as a user am I going to feel a difference in speed between
> if
>> I am the only user,
>> and if all 300 users are online at the same time.
>>
>
> You didn't specify how much memory you have but a conserative estimate
> would
> put the memory requirement at 300MB for the data described
>
> The answer really depends not on how many users you have but how many
> requests per second will be processed and how much of this session data is
> needed by those requests. A key problem area would be the arrays which
> need
> to be copied into the request execution context and if modified copied
> back
> to the session object. Each represents the copying of 100Kbytes and the
> allocation/deallocation 5000 strings.
>
> If you only get one request per second and only a sub-set of the arrays
> and
> other variables are used per request you could probably get away with
> this.
>
>> And if using of so many session variables not a good idea, so what's an
>> alternative?
>>
>
> An alternative is to use a Database. Store useful groups of values in a
> set
> of tables and of course each array in tables, each table should contain a
> key field that links the data to your session. You can then just store a
> few highly active session variables in the session object and store in the
> session object a key that represents your sessions data in the DB. You
> will
> need some housekeeping to eliminate data from sessions that are no longer
> active.
>
>
>> Regards,
>> Michael
>>
>>
>
>