Is it ok to take advantage of the fact that an inprocess dll keeps loaded in
an asp application?
I mean, create some expensive global objects once instead of recreating them
every time?

--
Looking for a C(99) compiler for windows?
Download lccwin32.
http://www.cs.virginia.edu/~lcc-win32/

IIS by default only maintains a pool of 10 of each object at any one time (I
think) and as such any usage beyond 10 concurrent accesses of the object
will be queued resulting in slower response times while prior requests are
executed.
However, this should only really come into effect for processes that take a
significant time to execute (eg. long running DB queries, updates etc.).
You can reduce this by hosting your objects in MTS and ensuring that the
objects are stateless (one method of achieving this is to store the state in
a database as opposed to persistent properties of the DLL class).
There's a few things to consider and a bit of research might be in order.
I do use DLL's on the server side to encapsulate complex functionality
(working with GIS mapping systems) but try to ensure that calls are as quick
as possible, the objects are stateless, and they are hosted in MTS with a
database maintaining the state information.

Hope this helps,

Chris.

[quoted text, click to view]
Is it ok to take advantage of the fact that an inprocess dll keeps loaded in
an asp application?
I mean, create some expensive global objects once instead of recreating them
every time?

--
Looking for a C(99) compiler for windows?
Download lccwin32.
http://www.cs.virginia.edu/~lcc-win32/

http://www.aspfaq.com/2053




[quoted text, click to view]

[quoted text, click to view]

You need to read the links in the article to understand why IIS' threading
model does not fit well into the scheme you propose... and remember that
you're actually going to have more overhead maintaining that
object/pointer/whatever in memory than the performance hit of instantiating
it. Instantiate it when you need it, release it when you're done with it.

[quoted text, click to view]

What I meant was something like the following.

There's a COM component that gets instantiated on some asp pages. The first
time the component is instantiated the dll gets loaded and stays resident in
memory until IIS is restarted. What I want to do is take advantage of this
and store a thread safe global variable that keeps a pointer to a C++ object
that is pretty heavy to instantiate every time. I don't want it on the
session or something, it's just a C++ object internal to the COM component.
Would that be ok?