How can I find why some classic asp pages randomly take a real long time to execute?

I'm working on a rather large classic asp / SQL Server application. A new version was rolled out a few months ago with a lot of new features, and I must have a very nasty bug somewhere : some very basic pages randomly take a very long time to execute.

A few clues :

• It isn't the database : when I run the query profiler, it doesn't detect any long running query
• When I launch IIS Diagnostic tools, reqviewer shows that the request is in state "processing"
• This can happen on ANY page
• I can't reproduce it easily, it's completely random.
• To have an idea of "a very long time" : this morning I had a page take more than 5 minutes to execute, when it normaly should be returned to the client in less than 100 ms.
• The application can handle rather large upload and download of files (up to 2 gb in size). This is also handled with a classic asp script, using SoftArtisan FileUp. Don't think it can cause the problem though, we've had these uploads for quite a while now.
• I've had the problem on two separate servers (in two separate locations, with different sets of data). One is running the application with good ol' SQL Server 2000 and the other runs SQL Server 2005. The web server is IIS 6 in both cases.

Any idea what the problem is or on how to solve that kind of problem ?

Thanks.

Sebastien

Edit :

The problem came from memory fragmentation. Some asp pages were used to download files from the server. File sizes could go from a few kb to more than 2 gb. These variations in size induced memory fragmentation. The asp pages could also take quite some time to execute (the time for the user to download the pages minus what is put in cache at IIS's level), which is not really standard for server pages that should execute quickly.

This is what I did to improve things :

• Put all the download logic in a single asp page with session turned off
• That allowed me to put that asp page in a specific pool that could be recycled every so often (download would now disturb the rest of the application no more)
• Turn on LFH (Low Fragmention Heap), which is not by default on Windows 2003, in order to reduce memory fragmentation

References for LFH :

• http://msdn.microsoft.com/en-us/library/aa366750(v=vs.85).aspx
• Link (there is a dll there that you can use to turn on LFH, but the article is in French. You'll have to learn our beautiful language now!)

Can you establish whether this is a problem for all pages or a common subset of pages?

If a subset examine what these pages have in common, for example they all use a specific COM dll, that other pages don't.

Does this problem affect multiple clients or just a few?

IOW is there an issue with a specific browser OS version.

Is this public or intranet?

Can you reproduce the problem from a client you own?