The question should be as following: Why is my SharePoint Farm down each time I’m Deploying, Retracting or Upgrading a Solution?
Deploying a solution:
Initially, the package manifest is parsed to find assemblies, application pages, JavaScript, CSS Files and other files that are not part of a Feature. These are copied to the locations specified in the manifest. All files contained within a Feature are copied to the Feature directory, a subdirectory of %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\TEMPLATE\FEATURES. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end web servers; the reset then deploys the files and restarts Internet Information Services (IIS). Farm administrators can specify when this occurs.
Retracting a solution:
Retracting a solution is the process of removing assemblies, files, resources, safe control entries, Features, and other solution components from computers to which they have been deployed.
In a complete retraction, features are uninstalled first from front-end web servers in the farm. If the solution is web application–specific, solution global files (if any) are removed when the solution is retracted from the last web application to which it is deployed.
Next, Features are uninstalled from databases. Feature-by-Feature, elements are removed from the configuration store. Finally, files are removed from servers in the farm. On individual servers, files that are associated with the Features and site definitions are removed.
On each front-end web server, the following occurs:
- Internet Information Services (IIS) is disabled.
- Files are removed from the system.
- IIS is re-enabled and Microsoft SharePoint Foundation is reloaded when a user browses to a page.
Upgrading a solution:
There are two ways to upgrade a farm solution. Which one is used depends on what kinds of changes have been made in the newer version of the solution.
Replacement: The old version of the solution is retracted, and optionally removed from the farm solution store. The new version is then added to the solution store and deployed. It is not necessary that the new solution package (.wsp file) have the same name or GUID as the old version, however, if the old version is retracted but not removed from the solution store, then the new version must have a different filename and GUID. This kind of upgrade must be used if the new version of the solution differs from the installed version in any of the following ways.
Update: A new version of the solution package is installed and deployed which has a different file name but the same GUID as the old version. The Microsoft SharePoint Foundation deployment infrastructure detects that the GUIDs are the same. It automatically retracts the old version before deploying the new version. If there are Features in the solution, then the new and old versions have the same set of Features and they remain activated but assemblies and certain other files in them are updated with the versions from the new solution package.
Conclusion:
Doesn’t matter with operation that you are executing for your Farm Solution (Deploy, Retract or Upgrade) an IISRESET will always occur. It’s as designed!
What does an IISReset?
When SharePoint uses the iisreset command in IIS 7.0, the IIS Admin Service, the Windows Process Activation Service (WAS), and the World Wide Web Publishing Service (WWW Service) are stopped and restarted. We should avoid using iisreset unless absolutely necessary, because the Web server shuts down all applications that depend on these three services until the services successfully restart. This means that you lose existing state in your applications, your Web sites and applications become unavailable, and you risk unpredictable results by stopping processes before they finish.
A Real Case: 46 Application Pools
The Microsoft recommended amount of IIS application pools per server is 10. These recommendations are dependent on hardware and load most of the time, but not during IISReset. During an IISReset all the application pools are brought down alphabetically and then brought back up. This takes +- 10 seconds per application pool. è More application pools è longer downtime.
After the installation of each SharePoint GAC solution an IISreset is performed / required by the system. è 10 solutions è 10 IISResets
I’ve tested deployment times on Development / Test machines and here are the results for deploying the same solution on different servers with different amount of application pools running.
| Application pools | Deployment time | Environment |
| 5 | 0:40min | Publishing |
| 11 | 1:26min | Staging |
| 20 | 2:56min | Authoring |
| 46 | 9:00min | Dev |
As you can see there is a consistent rise in deployment / downtime and the number of application pools.
A Real Case: Workaround
A simple calculation shows us the following: 9:00min X 10 solutions => 90 minutes downtime of your SharePoint Farm (DEV). The business is not happy with that cause their site is down and they cannot use it anymore for 90 minutes at least.
The question can be; why is SharePoint stopping one by one the application pools? What if I stop all the Application Pools manually, made my modification and start my Application Pools again manually?
Seems interesting; lets test ^^
Stopping Application Pools manually
On my server with 46 Application Pools it isn’t easy to bring each of them down. You can use the following script to bring down all your Application Pools:
Import-Module WebAdministration
$applicationPools = Get-ChildItem IIS:\AppPools | ? {$_.state -ne "Stopped"}
foreach($applicationPool in $applicationPools){
Write-host "Stopping application pool ""($($applicationPool.name)"""
$applicationPool.Stop() }
Updating the solution
When all the Application Pools are down please update your solution with the Update-SPSolution command (an example can be):
Update-SPSolution –Identity PEGASUS.solution1.wsp –LiteralPath “d:\Gokan\ PEGASUS.solution1.wsp” –GacDeployment
We can now check the SharePoint Logs:
11/09/2013 17:03:11 - Solution already exists and will be 'updated'
11/09/2013 17:03:12 - Update-SpSolution PEGASUS.solution1.wsp
11/09/2013 17:03:12 - Update source D:\SPRD2010\Runningjobs\ PEGASUS.solution1.wsp
11/09/2013 17:04:08 - Solution updated
Now that was fast! 1 minute in place of 9 minutes… Why? Cause we stopped manually the application pools and didn’t wait for the stop and start of each Application Pools that took a crazy time. Now we have to restart the 46 Application Pools again. You can use the following script to start all the application pools under your current farm.
Starting Application Pools manually
Import-Module WebAdministration
$applicationPools = Get-ChildItem IIS:\AppPools | ? {$_.state -ne "started"}
foreach($applicationPool in $applicationPools){
Write-host "Starting application pool ""($($applicationPool.name)"""
$applicationPool.Start() }
A Real Case: Easy words
- Stop all the Application Pools
- Update your Solution
- Start all the Application Pools
- Use Warm-up Script if necessary
Conclusion:
We conclude that the manual start and stop of Application Pools saves us valuable time. We’re avoiding 46 Application Pool restarts (one by one).
Again, this can be useful and will be useful when you have a Major Production Implementation on a Production server where best practices aren’t followed (As you know we shouldn’t have not more than10 Application Pool maximum per server).
Be preventive and make first enough conclusive tests on your development machines before going on Production Servers.
Reference from link
No comments:
Post a Comment