I have 3 applications on the same web server. Two of them are configured in separate ASP.NET 4 application pools and and one of them is on an ASP.NET 2 application pool.
I'm experiencing intermitent timeouts when accessing those apps during the day. To track down this timeouts, I have setup a ping monitoring service (motive.com). Here is a sample of the timeout ocurrencies log:
app date downtime main reason
APP2 19-September-2012, at 14:51 4 mins 50 secs connect() timed out!
APP1 19-September-2012, at 14:51 4 mins 50 secs connect() timed out!
APP2 19-September-2012, at 14:11 2 mins 50 secs couldn't connect to host
APP1 19-September-2012, at 14:11 2 mins 50 secs couldn't connect to host
APP2 19-September-2012, at 9:17 2 mins 41 secs couldn't connect to host
APP1 19-September-2012, at 9:17 2 mins 41 secs couldn't connect to host
...
As you can see, both ASP.net 4 pools are timing out simultaneously. I'm also monitoring the ASP.NET 2.0 app pool web site and I haven't have one single timeout!
There's no pattern whatsoever related to the time of the day that it occurs (both day/night). Intervals between timeouts don't follow a pattern either, sometimes they happen after 40 minutes, others take some hours in between.
The timeout never lasts more than 5 minutes, but they also vary from 2 to 5 minutes randomly.
At first I thought it might have something to do with application pool recycling but I've checked and recycling is set to occur after 24 hours and disabled for other events (memory peaks, etc.).
The site is infrequently accessed (it's in beta test), so there are no huge number of access, workers demand, memory consumption, etc.
I've also checked the IIS log and there are 2 to 5 minutes gaps during the hours of downtime reported by the monitoring service, but no error message. I also checked the Windows event log and haven't found anything unusual in system and application events.
I'm really desperate right now. If someone could help me out, I'd be really thankful.
Best Regards,
Eduardo de Freitas
It's hard to say, but one thing to check is in the web.config if you have This should be set to false, see this link for more details and additional items to look for: http://www.hanselman.com/blog/MostCommonASPNETSupportIssuesReportingFromDeepInsideMicrosoftDeveloperSupport.aspx
Related
I am having an issue with Web API hosted on IIS. Here are the details
Environment: ASP.Net MVC, IIS, SQL server
Web API hosted on separate server, Load balanced with 2 servers, Big
IP
The API works fine in PROD but in lower environments it becomes unresponsive or very slow. Sometimes it takes 5 minutes to process a request. Otherwise it takes forever. The issues occurs only once or twice a month. App Pool recycle or IIS restart didn’t seem to help. But after rebooting server it works fine and processes the same request in 10 – 20 seconds.
Authentication is set for every request (i.e. 401 followed by 200). When issue occurs the IIS log has only 401 entry. Issue seems to happen on only 1 server as it starts to work fine after restarting only that server.
During the issue when another API request comes, it gets to the affected server. What might be the reason that the request doesn’t go to another server which is free?
The system logs were fine. The CPU utilization was 3%, Memory usage etc. looks good on the server at the time of issue. IIS configuration settings are same as PROD and look good.
What tools can be used to monitor IIS Apps, Server? Are there any free tools? Any help to troubleshoot this issue will be great.
Some errors on server:
Activation of app Microsoft.Windows.Cortana_cw5n1h2txyewy!CortanaUI failed with error: This app can't be activated by the Built-in Administrator. See the Microsoft-Windows-TWinUI/Operational log for additional information.
The Open Procedure for service "BITS" in DLL "C:\Windows\System32\bitsperf.dll" failed. Performance data for this service will not be available. The first four bytes (DWORD) of the Data section contains the error code.
Windows cannot load the extensible counter DLL ASP.NET_2.0.50727. The first four bytes (DWORD) of the Data section contains the Windows error code.
Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.
UPDATE:
DebugDiag2 Analysis - CrashHangAnalysis report.
Is this causing deadlock?
Thread ID Total CPU Time Entry Point for Thread
2 00:00:00.031 ntdll!RtlReleaseSRWLockExclusive+2200
0 00:00:00.030 w3wp+2e50
1 00:00:00.000 nativerd!DllGetClassObject+24680
3 00:00:00.000 ntdll!RtlReleaseSRWLockExclusive+2200
4 00:00:00.000 w3tp!THREAD_POOL::CreateThreadPool+350
4 Threads (40% of all threads) have this same call stack.
Note: Grouping of identical threads can be disabled in the 'Preferences' tab of the Analysis Options
Thread 2 - System ID 4704
Entry point ntdll!RtlReleaseSRWLockExclusive+2200
Create time 9/20/2021 1:00:34 PM
Time spent in user mode 0 Days 00:00:00.000
Time spent in kernel mode 0 Days 00:00:00.031
This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.
Thread 3 - System ID 2576
Entry point ntdll!RtlReleaseSRWLockExclusive+2200
Create time 9/20/2021 1:00:34 PM
Time spent in user mode 0 Days 00:00:00.000
Time spent in kernel mode 0 Days 00:00:00.000
This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.
Thread 8 - System ID 2112
Entry point ntdll!RtlReleaseSRWLockExclusive+2200
Create time 9/20/2021 1:00:34 PM
Time spent in user mode 0 Days 00:00:00.000
Time spent in kernel mode 0 Days 00:00:00.000
This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.
Thread 9 - System ID 5832
Entry point ntdll!RtlReleaseSRWLockExclusive+2200
Create time 9/20/2021 1:01:04 PM
Time spent in user mode 0 Days 00:00:00.000
Time spent in kernel mode 0 Days 00:00:00.000
This thread is not fully resolved and may or may not be a problem. Further analysis of these threads may be required.
Instruction Address Source
[0x7ffadb029444] ntdll!NtWaitForWorkViaWorkerFactory+14
[0x7ffadaf9eb4e] ntdll!RtlReleaseSRWLockExclusive+296e
[0x7ffada7184d4] kernel32!BaseThreadInitThunk+14
[0x7ffadafd1781] ntdll!RtlUserThreadStart+21
I have a problem with my website and I think it's related to IIS recycling the app pool or shutting down the app after 20 mins of inactivity. As it is a low traffic site, when I first browse to the site the initial load can take up to 30 seconds, then after that it is very fast. If i then come back to the site say a few hours later I get the slow load time again. I'm sure it's something to do with the app pool shutting down after 20 mins of inactivity?
Another problem is that I am hosting via a hosting company so have no direct access to manipulate IIS at all. Does anyone know how I can keep my app alive so I don't suffer from the initial slow load speed issues?
You could setup a service to issue a request every few minutes to your site which can double as monitoring your site to ensure it's still running. You probably don't have access to the application pool configuration I assume.
I came across a post Concurrent firebase
As per top answer on the post if a user John come online at 12:00 , stay online for 24 hours , user Mike come online at 12:01 , stay online for 24 hours , user Jack come online at 12:02 , stay only for 24 hours, Then firebase have only 1 concurrent connection in 24 hours.
Did I understand correctly?
I was confused because I was thinking concurrent connection means connections to server at a time but as per explanation above concurrent connections mean connections start at same time?
I have no idea how you got from that accepted answer by #MikePugh to your conclusions. The text:
Concurrent connections are just that - connections established at the same time. So if you have 3 people using your app to check scores, but user 1's app goes online at 12:00 PM and the connection lasts for 5 seconds, then user 2's app goes online at 12:01 PM for 5 seconds, and user 3's app goes online at 12:02 PM for 5 seconds then you've only ever had 1 concurrent connection.
I added emphasis on the parts that you seem to have skipped in your copy.
In the example Mike gave, each user was connected only for a very short time. So there was never more than a single concurrent connection. In fact, for the majority of the day (23 hours 59 minutes 45 seconds) there were 0 connections. Given that Firebase bills at the 95th percentile, you'd be billed for 0 concurrent connections (if they'd offer such a tier).
You indicate that your users stay connected for 24 hours, which leads to 3 concurrent connections from 12:02 to midnight. So you'd have 3 concurrent connections for the majority of the time.
We have a web application deployed on IIS 7.5 target framework 4.0
the application perform slow when leave idle for few minutes for first time and then perform as expected this happened each time application is idle.
With the help of fiddler I found its TCP/IP connection which is taking time about 21 secs whilein subsequent calls this time is 0.
The Idle time out is also set high and connection time out is also high in the IIS settings.
server is - Windows 2008 R2.
there is nothing in the event viewer related to the website.
we used form authentication but the time out for that is also set about 10 hours in the config file.
Can anybody point me to the setting with is affecting the response time after the app is idle for some time.
Note - this was working proper when deployed withing the LAN but this problem starts when deployed out of the LAN or in separate domain.
Problem
here is the problem in IIS app pool idle time out, its by default set to 20 minutes, after 20 minutes app pool shutdown if no request within 20 minutes,
when any request comes after 20 minute its again start,
The problem is that the first visit to an app pool needs to create a new w3wp.exe worker process which is slow because the app pool needs to be created, ASP.NET or another framework needs to be loaded, and then your application needs to be loaded. so it may take time 20-30 seconds or depends on the application content size.
Solution
so to avoid this type of delay we need to set the idle time out to 0.
now it will always load fast.
app pool setting
The IIS application pool is shut down after 30 minutes of inactivity. After that, when you make a request IIS basically has to start the website up again, which leads to the behavior you are describing. You can change the idle time of your website in IIS though to avoid it.
You could also look into the Auto-Start feature of the 4.0 framework.
Well, a bit late, but may help someone else. I had the same problem, nothing in the logs, spent days, then looking at the network adapter properties / configuration / power management - Allow computer to shut down save power was checked. Unchecked and the problem was solved.
I have a asp.net website hosted in the dedicated server.I'm using web.config to handle the session timeouts and that is 60 minutes.I did the following settings on the dedicated server (windows server 2003 and IIS 6.0 versions)
In the default web site property of IIS-->ASP.net tab-->Edit configuration-->Session timeouts -->60
In the application pool The session timeout has been extended to 60.
Recycling worker process has been set to 60 in the application pool.
I can get this work correct on my local system the problem is on the dedicated server(Goddady). No customer support is available for this problem
It will be also fair if the session timeout is infinity too.
But the timeout occurs after every 20 minutes if the webform is kept idle. How to get rid of this? I have a guess that the idle timeout is overriding the session timeout as I googled around but have not found a solution for this
please help me........
Thanks,
Prabha
We had the same problem on a hosted server, and decided that rather than fighting with the hosting company we would use some javascript on a timer to execute an AJAX request to the server to reset the session if it was about to expire.
This site (PreventTimeout) is very close to what we do.
I know this doesn't answer your question directly, but it has been a good workaround for us.
If you recycle the application pool every 60 minutes, then (assuming your sessions die when the pool recycles) a session started 10 minutes before the pool recycles will only last 10 minutes.
On average, you'd expect a session to last 30 minutes.