Finding performance bottlenecks in a classic asp/s

Question

I've got an old classic asp/sql server app which is constantly throwing 500 errors/timeouts even though the load is not massive. Some of the DB queries are pretty intensive but nothing that should be causing it to fall over.

Are there any good pieces of software I can install on my server which will show up precisely where the bottlenecks are in either the asp or the DB?

Answer 1

Some tools you can try:

• HP (formerly Mercury) LoadRunner or Performance Center
• Visual Studio Application Center Test (Enterprise Editions only?)
• Microsoft Web Application Stress tool (aka WAS, aka "Homer"; predecessor to Application Center Test)
• WebLoad
• MS Visual Studio Analyzer if you want to trace through the application code. This can show you how long the app waits on DB calls, and what the SQL was that was used. You can then use the SQL profiler to tune the queries.

Answer 2

If you're happy that the DB queries are needfully intensive then perhaps you need to set more appropriate timeouts on those pages that use these queries.

Set the Server.ScriptTimeout to something larger, you may also need to set the timeout on ADO Command objects used by the script.

Answer 3

Have you tried running the SQL Server Profiler on the server? It will highlight any unexpected activity hitting the database from the app as well as help identifying badly performing queries.

Answer 4

Here's how I'd approach it.

1. Look at the running tasks on the server. Which is taking up more CPU time - SQL server or IIS? Most of the time, it will be SQL server and it certainly sounds that way based on your post. It's very rare that any ASP application actually does a lot of processing on the ASP side of things as opposed to the COM or SQL sides.

2. Use SQL Profiler to check out all the queries hitting the database server.

3. Deal with the low-hanging fruit first. Generally you will have a few "problem" queries that hit the database frequently and chew up a lot of time. Deal with these. (A truism in software development is that 10% of the code chews up 90% of the execution time...)

In addition to looking at query costs with SQL Profiler and Query Analyzer/SQL Studio and doing the normal SQL performance detective work you might also want to check if your database calls are returning inordinate amounts of data to your ASP code. I've seen cases where innocuous-looking queries returned HUGE amounts of unneeded data to ASP - the classic ("select * from tablename") kind of query written by lazy/inexperienced programmers that returns 10,000 huge rows when the programmer really only needed 1 field from 1 row. The reason I mention this special case is because these sorts of queries often have low execution times and low query costs on the SQL side of things and can therefore slip under the radar.

Answer 5

Where is the timeout occurring? Is it at lines when ASP is connecting/executing sql? If so your problem is either with the connection to the db server or at the db itself. Load up SQL profiler in MSSQL to see how long the queries take. Perhaps it is due to locks in the database.

Do you use transactions? If so make sure they do not lock your database for a long time. Make sure you use transactions in ADO and not on the entire ASP page. You can also ignore lock in SQL Selects by using WITH (NOLOCK) hint on tables.

Make sure you database is optimized with indexes.

Also make sure you are conencted to the DB for as shortest time as possible i.e (example not working code): conn.open; set rs = conn.execute(); rs.close; conn.close. So store recordsets in a variable instead of looping through while holding the connection to the DB open. A good way is to use GetRows() function in ADO.

Always explicitly close and set ADO objects to nothing. This can cause the connection to the DB to remain open.

Enable connection pooling.

Load ADO constants in global.asa if you are using them

Do not store any objects in session or application scopes.

Upgrade to latest versions of ADO, MDac, SQL Server service packs etc.

Are you sure the server can handle the load? Maybe upgrade it? Is it on shared hosting? Maybe your app is not the problem.

It is quite simple to measure a script performance by timing it from the 1 line to the last line. This way you can identify slow running pages.