Share via

SharePoint still slow to open first page - could be a problem with Microsoft CLR...

  • Article

Today a customer was very upset about the slow SharePoint to show the first page. This is one of the sore points of this amazing product, and generally everything is resolved with a little warmup script that performs a sort of pre-load the web pages before having users first logon. On occasion, however, as in the case of my client, the script might not be enough : (

In my rescue came the saints Bing and Google that showed me several solutions including, of all, that on Muhimbi blog site which can be summarize as: " A new approach to solve SharePoint’s painfully slow spin-up /
start-up time for first request "

Symptoms for STSADM:

  • You start STSADM without any parameters
  • There is a delay of about 30 seconds
  • 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:

  • 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.
  • There is a delay of about 2 minutes
  • 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.

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 a couple of workarounds, which one works best is for you to decide:

  1. Add crl.microsoft.com to your hosts file and point it to your local
    machine. Some people have reported success with this, but it didn't work for me.

  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

.

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 Next

With thanks to
Nik Shaw for the script.

Comments

  • Anonymous
    July 23, 2012
    You can work around this issue by configuring the Certificate Path validation settings Group Policy setting on the servers in your SharePoint Server farm so that the servers do not attempt to automatically update certificates. Check out blogs.msdn.com/.../project-server-2010-slow-load-times-of-pwa-and-sharepoint-pages.aspx

  • Anonymous
    July 25, 2012
    Good ! This could be another option to solve definetively this issue :)