On a site I'm working with, we've got two classes of changes they can ask for. On one hand, they've got stuff that I'd have to rebuild and redeploy. They count these as "downtime" changes, because we display a nice little splash screen and we test the site thoroughly when we come back up.
On the other hand, they ask us to do a number of text changes, turning features on and off, etc., which we've isolated to the web.config. We offer to do these either inside or outside of deployment windows - we just edit the file, check that the change is right, and go back to work.
But one of the smart guys on the client side pointed out that editing web.config recycles the app pool, and that's downtime right there. I'd never noticed, but I suppose that's right - while the app pool is unavailable, the app is "down".
But for how long? I'm not asking you to sort through the client's level of comfort with downtime intervals, but is this a common perspective? Or should we just not worry that web.config editing is accompanied by a second or two of application downtime?
All said so far is correct.
However there is a way to avoid this downtime, as long as your values you are pulling are not cached.
You can port part of your .config file to another file, that won't recylce the app pool.
It would look something like this in the web.config file:
<appSettings file="moresettings.config"></appSettings>
Then your outside file would look like this:
<?xml version="1.0" encoding="utf-8" ?>
<appSettings>
<add key="SOMEKEY" value="MYVALUE"/>
</appSettings>
IIS recycles the app pool by itself normally, and if those recycles don't cause you concern, this once shouldn't either.
The user shouldn't receive any sort of "service unavailable" errors, afaik.
If you're concerned at all with downtime, and this happens a lot, I would consider moving these settings to the database.
That said, the downtime in your case will be minimal. The app pool is recycled when you SAVE the web.config file, and we're talking milliseconds.
As said, IIS is indeed recycling the App Pool. This is not as bad as doing a full iisreset though - users shouldn't get the "Service unavailable." error as the Web Server is still online and serving requsts - it just has to wait for the AppPool to restart, which means that the response time for the users accessing in this moment are very high. This may be a problem of course if you have a public website and are turning visitors away.
The other side effects of AppPool recycling are the same as an iisreset: It flushes an InProc Session Cache if I'm not mistaken, and it executes the Application_Start event.
So even though it's relatively harmless, I would still treat it as downtime.
Related
We have a 2.x ASP.NET application, running on Windows Server 2k8R2.
We had to make a couple of changes and when we posted them to production the new changes are not working. When I check the physical page on the production server all of the new code is there, however the old code is still executing.
Something seems cached and I don't know where to check to un-cache it? I quickly restarted IIS but I can't bring server down for a long period of time until later tonight. I would like to figure out why this is happening so I can reset it now and also avoid it in the future. Any idea?
It's the same as refreshing the application pool. Do that instead, it's much faster!
I don't know what is causing the problem but I did find a fix. When I touch the web.config it recycles everything. So I edited by web.config, just added some black space and saved it. Once I did this my page refreshed properly. This allowed me to keep running the server. If I edit web.config multiple times it will lock up and I'll have to restart IIS (learned this the hard way a while back) but for a one time update so I can keep running until I can recycle later at night, it worked great.
In our production environment (only) an excessive number of sessions seem to be getting created from an ASP.NET web application. The eye-catching symptom was that the ASPStateTempSessions table was generating ~25K records per hour (when google analytics indicates less than 500 unique users on this site per hour). This is resulting in a high number of waiting tasks which is then causing slowdowns and issues across other databases and therefore impeding site performance. The vast majority of the sessions don't appear to have any significant amount of data in them.
Any thoughts on what could be causing the phantom sessions? I was originally thinking that image requests and the like were somehow causing new sessions, but that doesn't seem to be sufficient to explain such a high multiplier. Is that even reasonable? Should I explore that avenue further? Why would that not have the same symptoms in my development environment?
Thanks!
Environment Details (I can provide more details, I'm just not sure what else is relevant):
IIS 7
SQL Server 2008
Session mode is SQLServer:
<sessionState mode="SQLServer" sqlConnectionString="[Connection String]" allowCustomSqlDatabase="true" cookieless="false" timeout="120" cookieName="XYZ_SessionId" />
I agree that the likely culprit is flat files running the SessionStateModule, especially if you are using MVC instead of webforms. The reason is that in order to support extensionless URL routing, MVC adds the following tag into your web.config:
<modules runAllManagedModulesForAllRequests="true">
...
The attribute does pretty much what its name implies, which will cause you to experience overhead if you host images off of the same website in IIS. If you don't use extensionless URLs, you can consider turning off that attribute, or you can try moving images to a CDN like akamai or AWS cloudfront.
Alternatively you could look for a SessionStateModule alternative, there are some that exist that might provider alternate behavior. You could even roll your own by inheriting System.Web.SessionState.SessionStateStoreProviderBase, there is an MSDN article on doing that: custom session provider tutorial. If you do that last one, I recently found ResetItemTimeout to be the most commonly run item on every request by the default SessionState module.
Lastly, the reason I think that the expansion you are experiencing is being caused by this is the fact that SessionState module is synchronous by default. This means a browser requesting both imageA.jpg and imageB.jpg will receive imageA then imageB only after imageA has released the Session lock. This is much slower than the default behavior of a webserver, which is to serve up both on separate threads.
Another way to troubleshoot, if this does not solve it, is to look at the current requests going through IIS7. To do that, go to the top level server name in the left hand side of IIS manager and click on Worker Processes. It should list your website process, double-click that and it will show all current requests. You should see a ton of image files in there.
I'm a beginner in ASP.NET 2.0.Probably this could sound too basic and stupid issue for someone expert in the ASP.NET.But this is giving me sleepless nights.
Basically i have developed a simple multilingual website with a master page and content pages which fills inside the content place holder portions of the master page. The application works great when it is configured to run on the ASP.NET Development Server 2.0. But once i publish it to run on the IIS web server it will no longer function. :( I could see from the trace that none of the session variables i use are stored and redirected to the relevant content pages.
Although the contents are displayed, the session variable values by which i take some decisions on the redirected pages are lost and i run into exceptions.
Please guide me where am i going wrong and exact procedure for Publishing an application.
Ex: my home page has URL which runs something like
http://localhost/Onlineupdate/Home.aspx?vers=1.1&lang=fr-FR
Based on the above URL, i strip and save the vers and the lang variables in a Session variable. However these are lost when hosted on IIS.
There are a dozen or so things that could cause the session data to be lost:
IIS restarting
The app pool restarting
due to a change to the web.config
due to a change to anything in the \bin directory
memory limit reached, or a bug causing the app pool to reset.
several other possible causes
Your host is actually a web farm, and you're using in-process memory, which will cause issues when one server fails over to the other, unless you're using SQL Server session state mode.
Since we don't have enough information to answer exactly what's happening in your specific situation, I'd ask you to start by reading up, starting here: http://msdn.microsoft.com/en-us/library/ms178581.aspx
Edit: I did find this blog article, which may be helpful: http://blogs.msdn.com/b/amenon/archive/2007/08/21/troubleshooting-session-loss.aspx
The following is not necessarily part of the answer, but added to try to be helpful.
If it's feasible, from my own personal experience, we've had success in eliminating our lost session issues by using the SqlServer Session State mode. Since we implemented this, our session issues have all but disappeared.
also i found the main problem that you should initialize session before use
like:
session[“id”]=””;
and after that it well work fine
In order to prevent this to happen first in the web.config set restartOnExternalChanges to false.
Now in web.config changes must be propagated manually(this means that the dev is now responsible to build a mechanism for config change propagation).
Hint: You can use file watcher for this that will listen for the web.config (or any config you use in you web. app) for changes and wrap it as a watchable configuration so you can reload the configs when they are changed.
Hope this helps
I faced the same issue in my ASP.NET MVC website .
and i have resolve it by next steps :
open IIS Manager
go to the application pools
right click on the application pool which related to your website
click on "Advanced Settings"
set "Idle Time-out (minutes)" to be "20"
set "Maximum Worker Processes" to be "1"
Click Ok to close the window
these steps has resolved my issue.
Normally, I use App_Offline.htm for taking the site offline. But occasionally, when I do that, the site just hangs (like in: browsers wait forever, server gives no response at all). This seems to happen on an updateable site when I change something, like a control and afterward, when it doesn't go quick enough (site hangs), I place App_Offline.htm in the root of the website.
In most cases, this immediately takes down my site. But occasionally it doesn't. In those cases, I cannot just stop the website (when I restart, the behavior continues). Stopping the application pool doesn't let me restart the same app pool. The only two solution so far is restarting the whole IIS web service.
I'd like to prevent this from happening. Is this a bug in IIS not "breaking all actions" when App_Offline.htm is found? I use IIS 7 with Windows 2008 SP2 64 bit.
What I found was that my web.config file either had an error in it or was missing. When this is the case, app_offline.htm does not get processed.
IIS should not stop existing actions, only prevent new requests from going through: Will app_offline.htm stop current requests or just new requests?
It sounds like you are describing a scenario where you update a control, try to load a page, and IE is stuck loading. At this point you drop the app_offline.htm and expect to see that page immediately.
If you are making a completely separate/new request after putting app_offline.htm in place then you should see the page come up. However the existing request will not be affected as linked above.
If possible try deploying the app_offline.htm file prior to making the control change.
I am not sure what you mean by "Stopping the application pool doesn't let me restart the same app pool"...if you meant that you can't restart the pool immediately after stopping it, thats because it isn't stopped yet. Depending on the number of Worker Processes in that pool it may take a min for it to completely spin down so it can accept the start command.
Also, I would think you would have to restart the pool in order for the app_offline.htm to work effectively anyway.
Here's the thing.
Everytime when you open the .sln at the server, or updating the code, it will create the app_offline ticket in the root.
This is the feature from asp.net itself to prevent any access to disturb your development.
Delete the app_offline manually everytime after you open the .sln.
hope this help.
thanks.
Another possibility is a missing handler. The following handler is required:
ExtensionlessUrlHandler-Integrated-4.0
To fix the issue you need to at a minimum:
Wait the length of your website timeout to ensure all requests have finished.
Background processes kicked off from a web request will mean further extending the length of time you wait beyond the website timeout
Unload any unmanaged code by hooking into the DomainUnload or Application_End events
I'm waiting 3 minutes for App_Offline.htm to take affect and this seems has allowed App_Offline.htm to work as expected.
Following recent hardware problems, I attempted to switch a couple of our websites to use new, individual application pools. A test run on our staging server worked fine, and has had no visible negative consequences.
Unfortunately, trying the same operation on our live machine left one of our key applications struggling - my best guess is with some kind of mismatch in Session state. I could log in fine, but a few clicks later would be presented with a screen that was part login screen, but with all menus visible. This indicates to me that part of the system thinks the session had been lost (redirect to login page), but IIS itself had not lost the session (hence the menus showing on the master page).
I tried recycling all the Application Pools (new and old), and each website using IIS Manager. I also tried a single-space change to the web.config file, and a full release of the dll's. Still, I could intermittently use the system for a few clicks, do some useful stuff, then maybe find myself at a login screen again or similar. We have some logging and on some occasions I could see that the session was being timed-out after a couple of seconds, substantially less than the settings on the App-pool (default 20mins).
As soon as I switched the web site's app-pool back to the default, everything was ok again.
What have I missed? Any suggestions gratefully received!
EDIT:
Just thought... on the staging environment I did name the App-pool differently from the website name (e.g. Xxxx_Dev, Xxx_Test etc) but on live I just called it the same name as the website. Could this cause an issue?
do your various applications all use Forms Authentication? Have you specified unique path attributes in each form tag in the web.config under the Authentication tag?
OK. I think I've found the problem.
I was actually using an Application Pool that had been set up by someone else - of the expected name - but they had set it up with the Properties, Performance tab | Web Garden option to use 4 worker processes. I have now changed that to 1.
As the session state was being stored 'In Process' (the default), each time the connection hit a new thread it also essentially lost any stored session variables, as I now understand things.
Its early days, but a simple switch to the newly altered Application Pool (no restarts or web.config saves necessary thus far) and everything appears to be behaving normally.