I need to edit the web.config file on a live Sharepoint environment, but I'm unsure what will happen if I do (I want to output custom errors).
Will this cause the IIS6 worker process to recycle?
Will active users lose their session state because of this?
Or can I safely edit the file?
The application pool will restart and session state will be lost. Imagine each ASP.NET application (as defined in IIS) is a program on the desktop. Saving web.config will do something similar to closing the program and reopening it.
Yes. It will be recycled.
Yes. They will lose their session.
Yes. You can safely edit the file. I suggest you to read this MSDN article : Working with web.config Files in Windows SharePoint Services
Also if Session state is configured as out-of-process (database or service) then recycling the app pool won't lose any session state. This is as true for Sharepoint as it is for vanilla ASP.Net.
When you edit the web.config, It will restart the AppDomain (NOT AppPool) of that web application and clears the all occupied resources and memory. So other web applications running under that App Pool will not be affected. Also it will clear the sessions (in-proc) and memory cache.
As already mentioned by some people: the application pool of the site in IIS will restart (this typically takes a couple of seconds). As a result the next page request(s) will be slower (since nothing will be cached anymore). Also the session state of the users will be lost; BUT in WSS session state is not used by default, in MOSS it is used by InfoPath Form Services. So it could be that you don't have big issues related to losing session state.
On the other side; to overcome those issues: what is typically done is to create a SharePoint Solution (WSP) that deploys and starts a Timer Job to make the changes to the web.config from code (using the SPWebConfigModification class of the Object Model). The nice thing is that you can schedule the execution of the change, so your users won't notice it.
Related
For an ASP.NET Website where i am making updates. What would cause user sessions to reset?
From my understanding if i make any changes to files in the app_code folder or the global.asax file it will reset everyone's session but if i made a change to .cs file (in the top directory) it wont reset everyone's session?
Would it reset the session of anyone that was on that page that i updated?
Can someone help me with my understanding, thank you.
Assuming memory-based session (as opposed to sql server based).
Well, the app pool restart will blow out session.
(so, in some cases even un-handled errors will blow out session).
Modify web config?
that will case app pool to restart (and blow out session).
Update any folder outside of app_data. Again, app pool re-start (and blows out session).
change content of bin folder - again app pool re-starts, (and blows out session).
Update code behind (.cs, or vb pages (code behind)). - again, app pool re-starts, (and blows out session). (so anything that will cause a re-compile of code).
There are probably a good many more - the above is a basic list.
You can thus consider adopting sql session based, and that will thus be far more robust, and I even re-started IIS services, and users if not doing anything just looking at their web page while logged on? They were able to continue working even after a full re-start of IIS services.
On the other hand, I now always use a asp.net web site "applcation". Thus no souce code is placed on the web server, and my compile is done with visual studio before deploying. The only big issue is that if you change to a application deployment model, the even just changing one line of code behind will force/require a full re-publish of the web site.
It looks like you are using a web site, and thus source code (code behind) is placed on the web server. Thus, IIS has the job of re-compiling such code, and thus any code change will as a general rule cause a app_pool re-start, and thus loss of session.
As noted, if you change from in-memory session to SQL server based (turn that feature on), then most if not all of your session issues will go away. Even if you not using "application deployment" and have/use code behind on the site for IIS to re-compile? Then using sql server-based session management should fix all of your session() woes.
We would like to warm up an ASP.NET MVC application hosted on IIS 7.5 server. The warm up module that used to be available at http://forums.iis.net/t/1176740.aspx has been removed since sometime.
The application should be warmed up everytime IIS or ASP.NET worker-process restarts for any reason. During the warm up period, IIS should return some HTTP status code signifying its warm up state or its inability to serve any clients.
Would creating a executable that navigates through necessary pages in the site via HttpRequests be a good idea? The executable can be triggered from IProcessHostPreloadClient implementation. Is it possible to configure IIS so that it would only accept requests from localhost and once the executable is done, it can switch over to all clients - but that switch should not trigger an IIS restart (obviously).
Is it possible to use an Visual Studio 2010 - Web Performance Test to warm-up an application instead of creating an manual executable? Any other alternatives?
PS: The application uses Forms Authentication and uses sessions - so maintaining state cookie and other cookies is important.
UPDATE 1 - We are using .NET Framework 4.0 and Entity Framework (database first) in our application. The first time hits to EF queries are slow. The reason behind the warm up is to get these first time hits out of the way. We are already using compiled queries at most places and we have implemented pre-compiled views for EF. The size of the model and application is very large and complex. Warm up needs to walk through many pages to ensure that compiled and non-compiled EF queries get executed at-least once before any end user gets access to the application.
Microsoft has released a module that does exactly what you ask for. The Application Initialization Module for IIS 7.5 improves the responsiveness of Web sites by loading the Web applications before the first request arrives.
You can specify a series of Urls that IIS will preload before accepting requests from real users. I don't think you can get a true user login expereince, but maybe you can set up simulated pages that does not require login that fulfills the same warmup you ask for?
The feature I think is most compelling is that this module also enables overlapped process recycling. The following tutorial from IIS 8.0 include a step-by-step approach on how to enable overlapped process recycling.
When IIS detects that an active worker process is being recycled, IIS does not switch active traffic over to the new recycled worker process until the new worker process finishes running all application initialization Urls in the new process. This ensures that customers browsing your website don't see application initialization pages once an application is live and running.
This IIS Application Initialization module is built into IIS 8.0, but is available for download for IIS 7.5.
You may take a look at the following post for the Auto-Start feature built into IIS 7.5 and ASP.NET 4.0.
Any application that generates a server request for the hosted resources can be used to warm up an IIS process. Exactly how many requests you need depends on what parts need warming up. Typically, warm-up is used for:
Starting up a worker process. For this, you only need to ask for one resource to warm up a process for the entire application.
Perform any static initialization, database startup, or pre-caching. Anything you do in your Global.asax file will happen when you do your first request, so if you can make all of your initialization happen then, you'll still only need to make one page request.
Force pre-compilation of ASP.NET pages. For this to happen you would need to hit every page. Fortunately, this is typically not much of a time cost, so you likely don't need to worry about it. If you do have individual pages that load slowly, you can warm them up separately.
The "warm-up" process here isn't anything magical. You just need force IIS to serve the URL in question. Everything you mentioned would take care of that: using a stress-test tool to query the URL, writing a custom utility to post HTTP requests, even just scripting out a tool like 'wget' or a PowerShell script to download the URLs would do it.
As far as restricting access to localhost, as far as I know, within IIS, the only way to change that requires you to restart IIS. You could always build a pre-request hook into your application and maintain the state there, and have your warm-up process query some specific URL that toggles that state to "open". But I'm not sure what you would accomplish. If, somehow, a user did try to query your site before your warm-up finished, all that would happen is your site would take a long time to respond, then they would eventually get the page they asked for. If you locked them out of the site during warm-up, they would instead get a browser network error that claimed the site was offline, which (to me) sounds much worse.
My observations in my development setup:
I have a running ASP.NET application that displays localized resources from resx-files.
I change the resx-files while the app is running
Upon page refresh, the changed resources are correctly displayed in the ui
The session was killed by the refresh
I am using ASP.NET MVC3.
I am using InProc sessions.
I am running the application through VisualStudio 2010 on IIS Express.
Is the above behavior generally true, or only on my development setup:
Does a change in resx-files always trigger the recompilation of the application and consequently kill all InProc sessions?
Is this also the case on "production" IIS?
Is this somehow dependent on some configuration?
Does switching session state to stateserver or sqlserver solve this problem. Is it then possible to change resx-files while the app is running, having the changes reflected in the ui on reload and still preserving session state?
Yeah it looks like the session is cleared, since the cache needs to be re-created with the new values.
There is some discussion about it here:
http://forums.asp.net/t/1091924.aspx/1
Looks like you might have to work around it.
Our web-application is on .net 1.1 and we have some legacy code that hangs-up IIS after every couple of days.
I was thinking about modifying machine.config settings to restart aspnet process after every couple of days, but the problem is it's going to kill existing sessions in process. Can I avoid it somehow.
Is there a better way to deal with this situation? right now client restarts IIS manually after every couple of days.
Thanks,
A
Edit:
If you have
- un-serializable objects in your session,
- cant work with sql-server
Then the good work around is to use "idleTimeout". It shuts down asp_net process if there is no activity on the server until the time specified. On the next request, it spawns asp_net process.
I suggest two things:
Configure the application to use SQL Server to store session data - this allows the session data to survive a restart of the web application
Configure the application pool to recycle worker processes periodically:
Of course, even better would be to update the web application to a recent framework version and fix at the same time the problem to prevent this from happening in the first place.
Do you actually store any type of data in Session? if you do, is it Serializable? If it is, just change the Web.config to use StateServer.
You just need to start ASP .NET State Service automatically by going to control panel--> administrative tools --> Services and setting up ASP .NET State Server to start automatically.
This will allow you to restart the aspnet_wp.exe process w/o losing session information; again, the only requirement is that the information you put in session is Serializable (which is likely the case or at least should be easy to do if your the code is not doing anything crazy)
Scenario: I've an n-Tier enterprise ASP.NET application deployed using Web Deployment Projects. All tiers produce independent assemblies that is consumed by the ASP.NET application.
Problem: When I run the app. for the first time after deployment it takes lot of time to load dependent assemblies in memory. But once loaded its lighting fast app. In case if there are no users accessing the app, IIS unloads the assemblies from the memory and when a user tried to access the app on a later instance it goes on loading all the assemblies once again taking the same amount of time to load as it takes to do so for the first time.
I'm looking for a solution that enables me to keep my assemblies loaded into memory persistently overriding the volatile nature of assemblies towards memory residency.
Or any other solution that lets my users happily use the app resolving the mentioned problem.
In IIS 6, go to the Application Pools section, and right-click > Properties on the pool which hosts the ASP.NET application in question. Go to the Performance tab and uncheck "Shutdown worker processes after being idle for:"
In IIS 7, go to the Connections pane and find Application Pools, and select Advanced Settings for the pool which hosts your application. Find the "Idle Timeout" property and set it to "0" (this disables it).
The default is 20 minutes of inactivity. By unchecking the box, once your AppDomain is loaded by the worker process, it will never die (unless you kill the process or something of course). By default, IIS will recycle the process when it reaches some limit, such as a memory cap, but it will also start a new one and "phase over" all incoming requests until the old one is unused, so as to minimize disruption.
I've also written a small c# class which will keep your ASP.NET application alive (alternate archived version) under normal circumstances. Since it runs within the application, obviously it can't stop IIS or anything else from explicitly killing the process, but it will keep the application "hot", e.g. the app will never go idle long enough for IIS to decide to shut it off.
If you do not have direct control over your IIS configuration (shared host, for example) your best bet is to have a small application running on a separate system - say, an always-on workstation - which hits your site every x minutes to keep the application pool from timing out. Nothing fancy - a simple WebRequest and a while() loop in a console application will do.
One of the advantages of ASP .net is the posibility to create static (shared) instances of objects.
To avoid the necessity of an external process you can create an static timer in (per example) global.asax which calls for a page on the domain with a simple WebRequest. On this way the site keeps alive himself until a manual reset of the pool is done.
I wrote a little C# console application that keeps my 4 sites alive every 10 mins via windows task scheduler. Life is once again good. We do not run the app from 2-5am just so the serves can do any cleanups of memory, if it even matters. for our sites there is rarely anyone on at those hours anyway.