SharePoint Deployments Cause Disruptions for "Real World" scenarios

[Here is research I did a few years ago on WSP deployments in MOSS 2007.  I needed to understand which deployments would disrupt users.]

I’ve concluded a series of tests to determine if it’s possible to deploy a SharePoint Solution Package (WSP) for a given web application without disrupting other web applications in a SharePoint farm. I looked at the behavior of various stsadm deployment commands (AddSolution, DeploySolution, Retractsolution, DeleteSolution, ActivateFeature, DeactivateFeature), as well as components within the Solution Packages (WSP files). The results were not promising. In almost all tests, the deployment was disruptive - due to an IISRESET (the most disruptive) or App Pool recycling (less disruptive than an IISRESET).

The following actions were verified to cause disruptions:

• Feature Activations/Deactivations with SPWebConfigModification methods recycle all App Pools.
• Globally Deployed Solutions recycle all App Pools.
• Retractions (of any Global or Web Application Targeted WSP) trigger an IISRESET.
• Web Application targeted Solutions deployed or retracted using the -allcontenturls switch trigger an IISRESET.
• Web Application targeted Solutions deployed with GAC DLLs recycles the App Pool associated with the Web Application.
• Running stsadmin -o upgradesolution triggers an IISRESET.

I looked at 4 Solution Package scenarios:

Scenario 1 represents a minimal solution package, to emphasize the how the stsadm commands behave when a WSP contains almost nothing. Scenario 2 is more realistic, and reflects the typical WSP files we deploy at BigCompany. Here is more detail:

Scenario 1a - The WSP is minimal, containing a single ‘Custom Action” that adds a menu item to the Site Actions menu. No DLL, no web.config changes, no feature receiver or event handlers.

Scenario 1b - Same as Scenario 1a, but added a “do nothing” DLL that gets deployed to the GAC.

Scenario 2a - This represents a “codeless” deployment of a Master Page and related UI elements - with no DLL, no event handlers, no feature receiver. This is a typical BigCompany WSP scenario

Scenario 2b - Another typical BigCompany WSP scenario  - like scenario 2a, but added DLL for feature receiver code that updates web.config.

 

Test Results
The test results are shown in the two tables below. The only cases not causing disruptions were the initial Add/Deploy of a Web Application targeted solution package, and Feature Activation/Deactivation that does not update web.config via SPWebConfigModification methods. Of course, feature receivers can always perform an IISRESET through code, but that is not a recommended practice.

Disruptions Defined

In IIS 6 worker process isolation mode (the mode used in all BigCompany SharePoint farms), each IIS App Pool contains a single worker process (w3wp.exe). An App Pool hosts one or more ASP.NET web applications, which are isolated from each other by running in separate App Domains (a .NET concept) within the w3wp process.

When a web.config file is changed, the associated web application shuts down, and all new HTTP requests to the “shut down” web application are queued by IIS until a new instance of the web application is started within the w3wp process. The w3wp process keeps running, along with other web applications running in the w3wp process. Disruptions perceived by users are minimal…  delayed responses (not sure if http requests awaiting response from WFE are dropped).

 When an App Domain shuts down due to a web.config change, this event log message is generated:

 

When an App Pool is Stopped - the w3wp.exe process (and all ASP.NET apps running within it) is destroyed, and users see “the Service Unavailable” browser error message until the app pool is restarted again. Disruptions to users is more likely to be noticed. Recycling the App Pool is  a “kinder, gentler” version of a stoppage - because IIS will launch a new w3wp process, allow the “old” w3wp process to drain it’s requests, and redirect new HTTP requests to the “new” w3wp process. Users will likely see a delay, but without the “Service Unavailable” message.

IISRESET is similar to an App Pool Stop - but on a broader scale. All App Pools on the IIS machine are immediately stopped, and users will see “Service Unavailable” in their browser.

(note that while the diagram above shows the effect of IISRESET on a single WFE, IISRESETs generated by WSP Deployment timer jobs are done on every WFE).

Finally, the diagram below shows how SPWebConfigModification is unintentionally recycling all the App Pools – an unintended “nuclear option”.