If I have IIS 7.5 or newer, and I want to make sure my ASP.NET application hosted on IIS is as responsive and available as possible, one thing I do is usually setting the Start Automatically advanced setting for the app pool in IIS to true:
My question that I'm scratching my head about (and can't seem to find a definitive answer for) is: if the Start Automatically = true is set, does the Idle Time-out (minutes) setting have any effect?
As far as I understand, the Start Automatically setting makes sure the app pool is always up and running and available - so doesn't that kinda "kill off" the concept of an "idle timeout" ?
Start automatically as the description reveals, only enables the application pool upon creation or when IIS restarts. It has nothing to do with the other setting.
Related
I want to create an ASP.NET web site on IIS 6.1 (cannot be changed), that does not recycle nor shuts down. I want it to always be running and never be down not even for a second.
Are there any built-in features that can help me achieve this?
(I cannot create a Windows Service. I need a web site.)
The workaround and less preferable solution would be creating a regular web site and creating a windows scheduled task that calls a function in that web site in a fixed interval so it never recycles.
Do you know if IIS 7.* or IIS 8 support such a functionality?
** EDIT
It will be a web site running Hangfire for the background tasks.
Of course the Windows Service + Hangfire solution is better but because the lack of time and to keep it simple for our developers it is easier for us to maintain a web site which runs background jobs.
Depending on the framework, framework version, etc there might be different configurations that need to be accounted.
The best approach would be to check the official docs that asses this exact problem.
For example, if you build a .NET Core app, the steps for keeping an app alive are:
Managed pipeline mode: Integrated
Set start mode to “Always Running”.
Set Idle Time-Out (minutes) to 0.
Set Preload Enabled = True
Go to the Configuration Editor on your app, and navigate to system.webServer/applicationInitialization. Set the following settings:
doAppInitAfterRestart: True
Open up the Collection… ellipsis. On the next window, click Add and enter the following:
hostName: {URL host for your Hangfire application}
initializationPage: {path for your Hangfire dashboard, like /hangfire}
Under the app pool set the idleTimeout to 0. That will disable idle timeout recycling.
We have an application (ASP Dot Net , Framework 4.0) in production which is deployed on IIS 7.5 window server 2012. Every day this application gets around 4000 requests, but the problem we are facing for the last couple of days is that some of the users complain their session gets expired. We have checked the application and don't see any error that can get the session expired. We've checked the IIS setting and pool setting, but we don't see any reason fair enough to sort out the issue.
Please help us in this regard to get this sorted out.
Probably I need to give more detail that helps you resolve my issue.
We work in professional organisation where we run many application on IIS for our clients. The issue we receiving is coming on one of the same application we build for our new client and deployed on IIS 8.0 server 2012.
In web config of our application time out is for one hour and further we make sure that we shouldn't route the user to session expire page if any other error comes. Now after making these changes we are pretty sure that issue should not be due to application configuration or due to the structure of it.
Now we are concern about the IIS. The different thing this time is we are using IIS 8.0 not IIS 7.5 which we are using on our all different servers for different applications.
Some of the IIS configuration you might be interested
we have dedicated pool for the application further pool is configured 2.0 because application is on the framework 3.5.
maximum worker process = 1
Pool recycle in 28 hours
Let me know if you could guide me anything specifically if that is related to IIS 8.0 because we are thinking of reverting back to 7.5, its our production application and clients are keep complaining about it.
The Life time of a session of a user is set by the developer / yourself. So you have privilege to set the time a user session time out at the desired time. Here is the format of th declaration in the web.config.
<sessionState mode="Off|InProc|StateServer|SQLServer"
cookieless="true|false"
timeout="number of minutes"
stateConnectionString="tcpip=server:port"
sqlConnectionString="sql connection string"
stateNetworkTimeout="number of seconds"/>
You can set the creation of cookies to true or false
Decide / dictate where the session information needs to be stored(server, database..)
These are some of the links that can help.
MSDN
MSDN2
I guess, you might have allocated the default application pool for this application in the IIS and the same application pool might have been shared among other applications too.
Step1: You should allocate separate application pool for each site in the IIS.
Step2: in application pool --> advanced settings --> Change the maximum worker process count to 1
If the above solution is not working, better try the solution which is given in https://technet.microsoft.com/en-us/library/cc781036(WS.10).aspx
Hope this helps.
Maybe the answer is trivial, but I couldn't find the exact same behavior in other threads.
I have an MVC 5 web application. I implemented custom identity database with Asp.Net Identity 2 (Owin). I have only external login (facebook, google...etc). The login works fine. The users got authenticated with roles and everything.
After one minute of inactivity, my Visual Studio 2013 debug session stops. Sometimes the application remains available (so IIS App Pool is not stopped) sometimes it recycles IIS as well.
I also implemented logging in Application_End Global.asax method in order to have the shutdown reason, but in these cases there is no info in the logs. In other cases, when the App pool is recycled due to web.config change I do have info in the logs.
I suspect timeout, however I have no clue what kind of timeout it could be. Where should I look?
Thanks in advance.
I ran into the same problem, and found out how to set the timeout for IIS Express:
On the command window, navigate to the folder where IIS Express is installed, and execute the following appcmd command:
c:\Program Files (x86)\IIS Express> appcmd set config /section:applicationPools /[name='Clr4IntegratedAppPool'].processModel.idleTimeout:0.00:00:00
(scroll right to see the whole line)
Open IIS, find your application's AppPool, then:
Right click on the app pool and select Advanced Settings
Under "Process Model" set Idle Time-Out (minutes) to 0.
For reference, the only non-default (non-bold) settings in my "Process Model" and "Recycling" section are:
Identity : NetworkService
Idle Time-out (minutes) : 0
Ping Enabled : False
And with these settings, I can start up the debugger and it never seems to automatically time out or recycle.
Daniel I have had this exact same issue for a few months now and was about to go crazy about it. But I stumbled on a suggestion to run visual studio as administrator and that seems to have worked.
I have an asp.net app on IIS 7. It is 'pre-compiled', but I understand that IIS must still compile the assemblies the first time they're run.
Here is the problem--After I publish and deploy the application, I log in, and (as expected) it takes about 30 seconds to see the login page. Then I visit every page so that they are compiled (I have used the 'individual file for each page' or whatever option).
So far so good.
Then 10 minutes later i log in and it's near instantaneous. Still good and expected.
Yet the next day, my first logon takes 30 seconds or more again. Nobody changed web.config or copied any new assemblies in the meantime--this I am sure of.
Does anyone have an idea why this is happening? Is there an application timeout (as opposed to a session timeout)? Is there some setting in IIS admin console that I may have left at some default that is not optimal?
Thanks for any help on this,
James
Yes, starting an ASP.NET application in IIS is relatively slow. How much? It depends...
It's slow again the next day because IIS shuts down apps when they are inactive for some time.
The solution is "Application Initialization". This is built-in in IIS 8 and available out-of-band as a module for IIS 7.5:
http://www.iis.net/learn/get-started/whats-new-in-iis-8/iis-80-application-initialization
There is an Idle Time-Out on the Application Pool under Advanced Settings. Set this to 0 and the application will not stop due to inactivity.
I have a curious problem.
A 64-bit Windows 7 Pro box has IIS 7.5/64 installed. An application pool has been configured to enable 32-bit applications, and a site has been created using this application pool. However, when the worker process for the site starts, it is always started as a 64-bit process. The "bitness" of the app pool is evidenced in Task Manager, which has no "*32" tag with the w3wp.exe process name.
I've tried deleting and recreating the application pool, creating a new application pool, and re-registering the 32-bit framework, restarting IIS each time, all to no avail. I'm sure I'm overlooking something trivial, in "forest for the trees" mode, so a push in the right direction to clear up the fog would be appreciated.
I've read through several posts on issues like this, but most center on ensuring the app pool is configured to "Enable 32-bit apps," which was one of the first steps taken.
Have you set
enable32BitAppOnWin64
to true?
This is exposed as a property on the ApplicationPool class that can be set programmatically: ApplicationPool.Enable32BitAppOnWin64.
Also, here is a SO question about setting the property on IIS 7 (not sure if you are on Azure or not, but I believe the idea shold be transferrable to a non-Azure environment).
How to change property Enable32BitAppOnWin64 of Application Pool on IIS 7 on Windows Azure?
Finally, you could set it up in your Application Pool Defaults: http://www.iis.net/configreference/system.applicationhost/applicationpools/applicationpooldefaults
Well, after a couple of days of head scratching, I finally solved this problem.
After verifying through the IIS management tool that each application pool on the box had "Enable 32-bit Applications" explicitly set to True, I went into the machine's applicationHost.config, and those same pools had this property set to False. I manually edited these entries to True, restarted IIS, then re-registered the 32-bit version of ASP.NET, and the machine now operates properly.
Thanks for the suggestions. I'm not entirely why the IIS admin tool was essentially lying to me about the Enable 32 bit app setting, but oh, well... :)