D
David Swift
Hello.
I'm new to the news group and new to IIS. I'm trying to
help a client deal with memory usage issues in IIS. My
client is running IIS 5.0 on a Win2K box and is running
ASP scripts that both talk to an Active X Control written
in C++ as well calls directly into the ADO layer.
It seems that basic interaction with the ADO layer and
Active X Control causes the dllhost.exe process to use
more and more memory until the machine becomes wedged. It
seems that removing the interaction with the database and
with the Active X control helps significantly, but not
completely. I can make memory usage go up indefinitely
just by concatenating strings together in a loop. Once
the loop ends, the memory doesn't come back, even after 15
or 20 minutes of idle time. Switching to VB Script from
Java Script doesn't seem to help.
I'd like to know if there's a book out there or a
reasonably up to date web site that discusses best coding
practices for making database calls via ADO from IIS
approved scripting languages. My client's ASP scripts
seem to be matching the examples I've found online. The
scripts close connections after each call; the scripts set
all record set and connection objects to nothing/null when
complete.
I'd like to know also what constitutes reasonable ADO
usage from an ASP script. One of my client's pages
performs an outer query and then varying nested queries
while processing the records of the outer loop. The result
is potentially thousands of ADO queries. Trying to
display this page in particular can easily eat up 300
megabytes and that memory never comes back.
I'd like to know also if it's enough to set a handle to an
Active X Control to nothing/null when one finishes with it
in the scripting language when one finishes with it or if
something additional is required to ensure that its
resources are reclaimed.
I've spent a lot of time searching on Google for others
that may have run into this and found some horror stories
as well as success stories. This leads me to believe that
we probably have either a configuration problem or our
scripts are missing some key step or steps for releasing
resources.
Thanks for your help,
David Swift
I'm new to the news group and new to IIS. I'm trying to
help a client deal with memory usage issues in IIS. My
client is running IIS 5.0 on a Win2K box and is running
ASP scripts that both talk to an Active X Control written
in C++ as well calls directly into the ADO layer.
It seems that basic interaction with the ADO layer and
Active X Control causes the dllhost.exe process to use
more and more memory until the machine becomes wedged. It
seems that removing the interaction with the database and
with the Active X control helps significantly, but not
completely. I can make memory usage go up indefinitely
just by concatenating strings together in a loop. Once
the loop ends, the memory doesn't come back, even after 15
or 20 minutes of idle time. Switching to VB Script from
Java Script doesn't seem to help.
I'd like to know if there's a book out there or a
reasonably up to date web site that discusses best coding
practices for making database calls via ADO from IIS
approved scripting languages. My client's ASP scripts
seem to be matching the examples I've found online. The
scripts close connections after each call; the scripts set
all record set and connection objects to nothing/null when
complete.
I'd like to know also what constitutes reasonable ADO
usage from an ASP script. One of my client's pages
performs an outer query and then varying nested queries
while processing the records of the outer loop. The result
is potentially thousands of ADO queries. Trying to
display this page in particular can easily eat up 300
megabytes and that memory never comes back.
I'd like to know also if it's enough to set a handle to an
Active X Control to nothing/null when one finishes with it
in the scripting language when one finishes with it or if
something additional is required to ensure that its
resources are reclaimed.
I've spent a lot of time searching on Google for others
that may have run into this and found some horror stories
as well as success stories. This leads me to believe that
we probably have either a configuration problem or our
scripts are missing some key step or steps for releasing
resources.
Thanks for your help,
David Swift