By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,978 Members | 1,389 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,978 IT Pros & Developers. It's quick & easy.

ASP.Net intermittent slow response

P: n/a
Our production system developed a problem over the Thanksgiving weekend.
Wednesday evening... everything is fine. First thing Monday morning, we
started receiving complaints about the system being "slow".

I found that the web application will clip along without a problem and then,
for no apparent reason, it will "hang" for 15 to 30 seconds before returning
the page to the client. It appears that the http request is submitted to the
server and it "sits" on it. After it's released, the SQL query executes and
the page returns. There are no messages appearing in the windows event logs
(application, security, system), and I do not beleive that the worker
process is being recycled because users are not losing session state
(InProc).
I theorize that the problem is with ASP.Net because:

SQL Profiler shows normal response from SQL Server (once the query is
executed)
Evaluations of the network performance show no problems
Classic ASP pages are fine

The environment is:

Corporate intranet only (Windows authentication)
Win2k Server SP4
IIS 5.0
ASP.Net 1.0/ASP.Net 1.1 side-by-side (all apps are currently configured
to use 1.0)
Some classic ASP remains in the application
SQL Server 2000 SP3

I've tried a SQL Server restart/iisreset as well as a server reboot. I've
excluded inetpub\wwwroot from our antivirus (MacAfee) real-time monitor.
I've also tried using the application trace tool (trace.axd) but it doesn't
really show me anything useful for this situation.

This is severly hampering productivity for my users, but I don't know what
to do next to try and trace the problem. Is there a known issue that I've
not been able to track down? Are there any other tools out there that may
help me to see what's going on with the ASP.Net worker process.

Thanks in advance.
Nov 18 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Is all of this running on one box? If so, that could definately cause
slowdowns....
"Aaron McAlpine" <ti******@hotmail.com> wrote in message
news:tK********************@comcast.com...
Our production system developed a problem over the Thanksgiving weekend.
Wednesday evening... everything is fine. First thing Monday morning, we
started receiving complaints about the system being "slow".

I found that the web application will clip along without a problem and then, for no apparent reason, it will "hang" for 15 to 30 seconds before returning the page to the client. It appears that the http request is submitted to the server and it "sits" on it. After it's released, the SQL query executes and the page returns. There are no messages appearing in the windows event logs (application, security, system), and I do not beleive that the worker
process is being recycled because users are not losing session state
(InProc).
I theorize that the problem is with ASP.Net because:

SQL Profiler shows normal response from SQL Server (once the query is
executed)
Evaluations of the network performance show no problems
Classic ASP pages are fine

The environment is:

Corporate intranet only (Windows authentication)
Win2k Server SP4
IIS 5.0
ASP.Net 1.0/ASP.Net 1.1 side-by-side (all apps are currently configured to use 1.0)
Some classic ASP remains in the application
SQL Server 2000 SP3

I've tried a SQL Server restart/iisreset as well as a server reboot. I've
excluded inetpub\wwwroot from our antivirus (MacAfee) real-time monitor.
I've also tried using the application trace tool (trace.axd) but it doesn't really show me anything useful for this situation.

This is severly hampering productivity for my users, but I don't know what
to do next to try and trace the problem. Is there a known issue that I've
not been able to track down? Are there any other tools out there that may
help me to see what's going on with the ASP.Net worker process.

Thanks in advance.

Nov 18 '05 #2

P: n/a
It is on one box, but it's been that way for over a year now. The problem
just started yesterday.

"Scot Kelly" <sc********@hotmail.com> wrote in message
news:uF**************@TK2MSFTNGP10.phx.gbl...
Is all of this running on one box? If so, that could definately cause
slowdowns....
"Aaron McAlpine" <ti******@hotmail.com> wrote in message
news:tK********************@comcast.com...
Our production system developed a problem over the Thanksgiving weekend.
Wednesday evening... everything is fine. First thing Monday morning, we
started receiving complaints about the system being "slow".

I found that the web application will clip along without a problem and

then,
for no apparent reason, it will "hang" for 15 to 30 seconds before

returning
the page to the client. It appears that the http request is submitted to

the
server and it "sits" on it. After it's released, the SQL query executes

and
the page returns. There are no messages appearing in the windows event

logs
(application, security, system), and I do not beleive that the worker
process is being recycled because users are not losing session state
(InProc).
I theorize that the problem is with ASP.Net because:

SQL Profiler shows normal response from SQL Server (once the query is executed)
Evaluations of the network performance show no problems
Classic ASP pages are fine

The environment is:

Corporate intranet only (Windows authentication)
Win2k Server SP4
IIS 5.0
ASP.Net 1.0/ASP.Net 1.1 side-by-side (all apps are currently

configured
to use 1.0)
Some classic ASP remains in the application
SQL Server 2000 SP3

I've tried a SQL Server restart/iisreset as well as a server reboot. I've excluded inetpub\wwwroot from our antivirus (MacAfee) real-time monitor.
I've also tried using the application trace tool (trace.axd) but it

doesn't
really show me anything useful for this situation.

This is severly hampering productivity for my users, but I don't know what to do next to try and trace the problem. Is there a known issue that I've not been able to track down? Are there any other tools out there that may help me to see what's going on with the ASP.Net worker process.

Thanks in advance.


Nov 18 '05 #3

P: n/a
For anyone interested:

My problem ended up being related to Windows authentication. Our company is
in the process of flattening multiple domains into a single domain using
Active Directory. The server was on the old domain and moving it to the new
domain solved the problem. Although I don't know what the actual problem
was, it was definitely an authentication issue. Apparently the slowness was
a timeout while authenticating the user. I proved it by building two sample
applications. One had authentication mode = "None" and the other was set to
"Windows". The app using Windows authentication had the response time issue
and the other did not.

I hope this helps someone that may be having this frustrating problem.
Nov 18 '05 #4

P: n/a
Hi Aaron,

Thanks for taking the time to post this. When one has lost time on an issue,
it is easier just to move on and catch up.

I'm sure someone will find this in Google one day and silently thank you.

"Aaron McAlpine" <ti******@hotmail.com> wrote in message
news:V4********************@comcast.com...
For anyone interested:

My problem ended up being related to Windows authentication. Our company is in the process of flattening multiple domains into a single domain using
Active Directory. The server was on the old domain and moving it to the new domain solved the problem. Although I don't know what the actual problem
was, it was definitely an authentication issue. Apparently the slowness was a timeout while authenticating the user. I proved it by building two sample applications. One had authentication mode = "None" and the other was set to "Windows". The app using Windows authentication had the response time issue and the other did not.

I hope this helps someone that may be having this frustrating problem.

Nov 18 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.