SharePoint’s slow spin-up / start-up time for first request

Info from here

Ever since SharePoint 2007 was introduced we have all been really disappointed with the 2 minute spin-up time of the sites and the 30 second wait when launching STSADM. There are multiple factors that affect initial load time. There is the ‘loading of the assemblies and associated pre-compilation’ wait time, which can be solved by faster hardware, and then there is the problem outlined below, which may or may not be present in your environment. As it turns out this problem does not occur on all SharePoint installations, it only happens under a certain combination of circumstances.

Symptoms for STSADM:

1. You start STSADM without any parameters

2. There is a delay of about 30 seconds

3. While you are waiting, and tearing your hair out because your deployment script has about 60 STSADM commands, there is no CPU activity, swapping or significant network traffic.

Symptoms for SharePoint sites:

1. You make the first request of the day, or the first request after recycling the app pool because you are developing assemblies that sit in the GAC.

2. There is a delay of about 2 minutes

3. While you are waiting, and tearing your remaining hair out because you know you have to do this at least 50 times today, there is no CPU activity, swapping or significant network traffic.

Note: SQL Server 2005, which appears under certain circumstances to suffer from the same problem as SharePoint 2007.

The problem is that when loading signed assemblies the .net Framework checks the Internet based Certificate Revocation List. As our servers have, like most secure environments, no outgoing connections to the public Internet, the connection to crl.microsoft.com times out after what appears to be 30 seconds. It probably does this a couple of times in succession, causing a 2 minute wait when spinning up SharePoint.

After the timeout the assembly is still loaded and the software works as expected, though very slow every time a new signed assembly is loaded for the first time, which happens a lot. The worst thing is that no entries are written to the event log and no exceptions are thrown so you are left completely in the dark about why your application is so bloody slow.

There are 3 workarounds, option 1 is recommended

1. Add crl.microsoft.com to your hosts file and point it to your server but first download the CRLs and add them to the server manually.

a. Add an entry to hosts file on the SharePoint machine(s) pointing crl.microsoft.com to 127.0.0.1

b. Download the CRLs and add them to the server manually:

http://crl.microsoft.com/pki/crl/products/CodeSignPCA.crl

http://crl.microsoft.com/pki/crl/products/CodeSignPCA2.crl

c. Add them:

certutil -addstore CA CodeSignPCA.crl

certutil -addstore CA CodeSignPCA2.crl

2. Allow your servers to directly connect to crl.microsoft.com. If your environment dictates the use of a proxy server, configure it using proxycfg.

3. Disable the CRL check by modifying the registry for all user accounts that use STSADM and all service accounts used by SharePoint. Find yourself a group policy wizard or run the vbscript at the end of this posting to help you out. Alternatively you can manually modify the registry for each account:

[HKEY_USERS\<userid>\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing]

"State"=dword:00023e00

VBScript to apply registry change: The following script applies the registry change to all users on a server. This will solve the spin-up time for the service accounts, interactive users and new users.

const HKEY_USERS = &H80000003

strComputer = "."

Set objReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" _

& strComputer & "\root\default:StdRegProv")

strKeyPath = ""

objReg.EnumKey HKEY_USERS, strKeyPath, arrSubKeys

strKeyPath = "\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing"

For Each subkey In arrSubKeys

objReg.SetDWORDValue HKEY_USERS, subkey & strKeyPath, "State", 146944

Advertisements