Re: Storing objects in Session Variables - exactly why not?

From: Bob Barrows [MVP] (reb01501_at_NOyahoo.SPAMcom)
Date: 03/27/05 

Date: Sun, 27 Mar 2005 09:51:26 -0500

Thomas wrote:
>> Microsoft has published results of stress tests indicating the
>> opposite of what you say your results are. I suspect you were not
>> actually taking
>> adbantage of session pooling when you ran your tests, but of course,
>> this is only a suspicion.
>
> hmm thats interesting.
> wouldn't be OLE DB connections pooled when using default settings?

Yes, in IIS, session pooling is on by default (which can be confirmed by
reading the material in the links I provided). However, there are coding
practices that will cause it to be disabled. A quick perusal of your code
does not reveal any of the practices i was thinking of.

<snip>

Thanks for the code. I will try it myself sometime.
Can you share the results of your tests? How much of a difference was
achieved by using the Session-bound object?

PS. Have you at least changed the threading model of your ADO objects by
using the makfre15.bat batch file which can be found in your ADO folder? If
you are not using Jet, you really should do this. Most of my objections to
caching the object in session go away if you change the treading model.
>
>
> what about the Server.CreateObject? i always thought object creation
> and instantiation would add heavy overhead... and thus negatively affect
> performance
>

In earlier versions of IIS, it was always recommended that you get MTS
involved by using Server.CreateObject. In later versions (5.1 and higher, I
think) the reasons for encouraging the use of server.createobject have been
resolved. Performance can be improved by using the vbscript version of
CreateObject (simply leave out the "Server.")

Would it be too much to ask for you to repeat your tests using CreateObject
instead of Server.CreateObject?

>>
>> By taking advantage of session pooling, you minimize the number of
>> connections to your database. Don't forget: each connection uses
>> memory on the database server as well as the web server (assuming you are
>> using a server-based dbms, which you must be with 900 concurrent users).
>
> thats true. the db shows quite a lot of connections. but because of
> the 900 concurrent users are not all firing queries at the same time, the
> db
> is not overloaded. of course the memory requirements are quite huge, db +
> web uses around 2.5gb of memmory :-)
>
Not only that, but you also may be violating your license agreement for your
database server. But I am not a lawyer. Just providing some food for
thought.

Have a good Easter,
Bob Barrows 

-- 
Microsoft MVP - ASP/ASP.NET
Please reply to the newsgroup. This email account is my spam trap so I
don't check it very often. If you must reply off-line, then remove the
"NO SPAM"