Hi Brad,
1. On Windows 2000, you can't. All ASP.NET applications run under the
aspnet_wp.exe process. The quick answer to your question is to move to
Windows Server 2003.
2. You'll need to spin up a new thread to handle the query. You can use
an async call to do it which essentially does the same thing. The
Framework documentation contains examples, etc.
3. You will need to set Server.ScriptTimeout to a larger value. You will
also need to make sure that debug is set to false in the <compilation>
element in your configuration file. Additionally, you will want to
probably increase the responseDeadlockInterval in the machine.config file
so that it doesn't cycle the process after 3 minutes.
4. Impossible to answer with any degree of certainty without a code
review. One generic comment I'll make is that many developers do not make
correct use of caching to alleviate problems in this area. Here is a good
article for review:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html
/aspnet-cachingtechniquesbestpract.asp?frame=true
Jim Cheshire [MSFT]
MCP+I, MCSE, MCSD, MCDBA
ASP.NET Developer Support
(e-mail address removed)
This post is provided "AS-IS" with no warranties and confers no rights.
--------------------
| From: "BradC" <
[email protected]>
| References: <#
[email protected]>
<
[email protected]>
| Subject: Re: ASP.NET pages occasionally time out
| Date: Fri, 12 Nov 2004 08:43:55 -0600
| Lines: 56
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
| X-RFC2646: Format=Flowed; Response
| Message-ID: <
[email protected]>
| Newsgroups: microsoft.public.dotnet.framework.aspnet
| NNTP-Posting-Host: host195.nordyne.com 65.245.164.195
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09
.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.framework.aspnet:275591
| X-Tomcat-NG: microsoft.public.dotnet.framework.aspnet
|
| Thanks, Jim and Darrel.
| Here's an update.
|
| One of the two ASP.NET sites is a pretty straight-forward site that uses
a
| database to store the page content separate from the layout and style,
and
| allow customers to pull up information on several different services.
|
| The OTHER web app, however, is a web app designed to query a very LARGE
| database and return query results either on the page itself, or by means
of
| a downloadable XLS file.
|
| Turns out I didn't have anything in the second application preventing
users
| from trying to run a query on the entire recordset (over 280,000
records).
| Any query that would have returned results of about 35,000 or over was
| locking up the aspnet_wp.exe process, and the client page was timing out
| before any results were returned.
|
| Rebooting fixed the problem because it killed the aspnet_wp.exe process.
| I fixed it temporarily by hard-coding a limit of 32,000 into the query
| results, which processes and returns a page in a little over 2 minutes.
|
| SO, my next problem: (several problems, actually)
| 1) How do I keep big giant queries in one ASP.NET app from affecting the
| performance of my other applications?
| 2) How can I show users running queries a "query in progress" page while
| data is being retrieved? Any easy way to actually put a progress bar on
it?
| 3) Is there any way to ALLOW retrieval of very large data sets without
the
| client timing out? My client says that he would like to push the limit up
to
| at least 65,000.
| 4) Are there better ways of retrieving large datasets than how I'm doing
it?
| (I'm giving the user a choice--display the results in an on-page table
with
| optional paging, or download as XLS. To download as XLS, I'm taking the
| results of the table html, pushing it into a datastream, and rebadging it
as
| XLS. Excel is smart enough to open it up correctly even thought its
really
| only a HTML file with a giant table inside.)
|
| I know that these are not simple questions, but any ideas you might have
| would be greatly appreciated.
|
| BradC
|
| | >
| >> Any ideas you might have or directions I should start looking in would
be
| >> greatly appreciated.
| >
| > We had a similiar problem...I don't remember the exact symptom, but we
had
| > to reboot every two weeks or so. It turned out that there were a few
SQL
| > calls that weren't being closed, so, overtime, it was just running out
of
| > memory. We fixed those and it's been fine since.
| >
| > -Darrel
| >
|
|
|