Ecommerce Server Requires Daily Reboot

[dm1608]

I have an Ecommerce application that uses mostly ASP and a bit of ASP.NET.
Monitoring the servers memory via SNMP every 5 minutes would indicate that
there is a memory leak somewhere within the application. Of course, the
vendor says its a "Microsoft IIS" issue and tells us to reboot the server
each day or kill the worker process for IIS.

We're currently rebooting our server at 4 AM each night.

This is a really lame idea, in my opinion, because we always have at least
50 users on the site during the night and over 200 concurrently during the
day.

Does anyone know a good way to fix this problem?

We're using W2K Advanced and have 4GB of RAM and SQL 2000.

All service packs are up to date.

 

[Raymond]

I've worked with similar setups with even heavier
loads and they didn't need daily rebooting. So it's
not IIS per se. Check the event log. Are you using
session objects, com components? I always avoided
that session object in classic ASP like the plague.
How is the CPU load? Is IIS application protection set
to Medium pooled?

http://support.microsoft.com/default.aspx?scid=kb;en-us;811140

 

[dm1608]

I'll check those options.

In my opinion, the application is just poorily designed.

In order for customer to access webpage login, they have to know the virtual
directory and 3-4 querystring parameters. This usually isn't a problem when
it is bookmarked from another site. Virtually impossible for someone to try
and remember.

One of the querystring is a customer id #. We can host multiple customer
web pages that are unique in style/theme on our server. The issue is,
each web page has to query SQL Server to pull out "Theme" information...
such as button path, image, HTML attributes for header, footer, body, etc.
When there is a high load on the server, SQL Server is really busy doing
reads for every page view. Very lame.

What we have experienced as well, with the memory leak issue, as memory
resources run out... some customes actually see other customers' "Theme"
even though they logged on with the correct querystring.

The vendors answer is to reboot or create a job to kill the workerprocess
each day or when its memory reaches a particular threshold.

 

[Raymond]

Sounds like you need a good ASP developer to go through
the code, correct logic and optimize. There are a whole
bunch of things that can be done to make ASP apps faster,
everything from reducing delimiter transitions, to custom
SQL data caching schemes, to IIS settings, etc, etc, etc.

Just a few of them:
1) Use the same exact conn string for each DB across
apps. This helps connection pooling. Usually the conn
string should be stored in an app variable and used as such in
all pages. It's both good coding practice and easier on the
servers.

2) Keep SQL connections short, dump recordsets
into multi-dimensional arrays using getrows() and use
those arrays to access the data. This is often much faster
both for SQL and the web server than iterating through
the recordset. And of course, use sprocs, they're both
faster and more secure than ad-hocs.

3) In 3.0/Win2k, multiple Response.Writes are faster
than string concating multiple times and using one
Response.Write.

4) Watch out for infinite loops! Once common mistake
is where the recordset is put through a while loop but
then nothing is added to movenext in the recordset.
This then causes a massive spike in CPU usage 'til
the script timesout .

5) Don't use sessions! Use cookies and some custom
functions instead. Then remove/disable sessions entirely.

6) Use the approprate locks, transactions, and cursors.
Try to avoid serializable! And watch out how you define
indexes, defaults, and constraints. Indexes, especially clustered ones
are sometimes murder on updates and inserts, especially if
there are a lot of non-sequential inserts and deletes.

7) If a particular set of data hardly ever changes, consider
removing DB access for that entirely and simply hard-coding
it in ASP. If it changes but not often, consider some type of
caching scheme, where all or most of the data is loaded off
a file cache on the web server. This one requires quite a bit
of coding and change in classic ASP.

8) In IIS, make sure output buffering is enabled. It's enabled by
default in 3.0. I also prefer the default application isolation,
ie Medium pooled. Don't log everything unless you have
to. And watch out for viral scans on the global.asa file. Exclude
the global.asa from the scan. If IIS loses track of that file during
the scan, it can automatically restart the app.