Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a load balanced, virtualized windows authenticated sharepoint 2010 farm. I also have a similar setup on another farm.

Now the issue is that about the first load page load performance issue after an IISRESET. In fact both the Farms are slow for the first load. Farm1 takes only 15 seconds whereas Farm2 takes 90+ seconds to render the same page. I agree that its normal to take 15 seconds during first load but 90+ seconds!?

I copy paste here what I mean by it (taken from the developer dashboard enabled):

Page Load after an IISRESET

Request (GET:http://sp.comp.com:80/sites/def/Pages/Home.aspx) (91795.54 ms) BeginRequestHandler (0.30 ms) PostAuthenticateRequestHandler (0.09 ms) PostResolveRequestCacheHandler (70840.73 ms) ExecuteOnChannel:GetProfileProperties (57873.59 ms) CreateChannelAsProcess:Microsoft.Office.Server.UserProfiles.IProfilePropertyService (57208.08 ms) GetProcessSecurityTokenForServiceContext (57200.28 ms) CreateChannelWithIssuedToken (6.67 ms) InitializeWcfOperation (0.10 ms) ExecuteWcfOperation:http://Microsoft.Office.Server.UserProfiles/GetProfileProperties (83.99 ms) CleanUpWcfOperation (0.02 ms) GetWebPartPageContent (4401.46 ms) GetFileAndMetaInfo (4397.77 ms) Proxy Channel call for Enterprise Metadata Service (1131.88 ms)

Subsequent Page Load of the same page

Request (GET: http://sp.comp.com:80/sites/def/Pages/Home.aspx) (930.62 ms) BeginRequestHandler (0.11 ms) PostAuthenticateRequestHandler (0.09 ms) PostResolveRequestCacheHandler (84.69 ms) GetWebPartPageContent (79.86 ms) GetFileAndMetaInfo (77.24 ms) PortalSiteMapDataSource: Determining Starting Node (0.05 ms) PortalSiteMapDataSource: Determining Starting Node#1 (0.02 ms) Add WebParts (10.82 ms) CompUserPreferenceWebPart (0.89 ms) Newsbytes (3.18 ms) Comp Home (3.21 ms)

Findings so far: I found that if I were to uncheck the User Profile Service & the Metadata Service from this page’s associated web app, the first load is much faster - about 20 seconds. I’ve also verified disabling the antivirus checking on all servers.

Some other significant entries that I noticed from the Logs are:

0x0EE8 SharePoint Foundation Monitoring
b4ly Verbose Leaving Monitored Scope (GetProcessSecurityTokenForServiceContext). Execution Time=57510.6440902405

I also noticed another entry, which helped me rule out the possibility of any wait for certificate validation:

SharePoint Foundation Monitoring b4ly Verbose Leaving Monitored Scope (SPCertificateValidator.Validate). Execution Time=10.3105282934004

Another entry I noticed which I’ve no idea is about (since I use windows auth):

Monitored Scope (SPClaimProviderOperations.ClaimsForEntity()). Execution Time=22051.8979367489

Any ideas on the purpose or function of GetProcessSecurityTokenForServiceContext ? Does it relate to the User profile service and the Metadata Service. What about SPClaimProviderOperations.ClaimsForEntity

share|improve this question
add comment

3 Answers 3

There is a 'known issue' with SharePoint's initial load. SharePoint runs on the .Net framework on IIS, which goes to sleep by itself, or in your case an IISRESET restarts all the services.

Though the IIS services are running, nothing is going on until that first request is made to the website. At that moment, the .Net Framework has to compile all of the DLLs that comprises SharePoint and its features. So the initial load will take a long time, and the more services/features you're using (User Profile, Metadata, etc), the longer it'll feel as it all wakes up.

HTH

share|improve this answer
add comment

GetProcessSecurityTokenForServiceContext is the Get for security tokens for sharepoint services. So yes it does have a bearing on both, and all services. Something is misconfigured to do with either a service proxy (remove and r-eadd the service might fix this), network or permissions.

GetProcessSecurityTokenForServiceContext is a monitored scope also so errors around this should be easy to trace.

Microsoft.SharePoint.SPSecurityContext.GetProcessSecurityTokenForServiceContext if you want to reflect the dll and take a look for your own musings.

Failing all these steps, then further diagnostics using windows logs, SP developer window, uls and perfmon (You can view sharepoint service applications here).

share|improve this answer
add comment

I had the very same issue and yes it did take over 90 seconds at times. I did try a bunch of warm up scripts but we couldnt time it right because we lacked a defined usage profile. The extended time is due to the JIT/compile delay (as david Lozzi on your first answer indicated) and is expected (believe it) behaviour.

Here a couiple of steps I followed and it did make a slight difference: 1.Went to Central Admin -> Manage Web Applications -> Checked the web app - general setting Browserfilehandling was on Strict so changed it to Permissive.

2.Also ran the following command on the SP server and SQL Server and rebooted both servers: netsh int tcp set global chimney=disabled

3.Went to Services console and stopped the timer service and cleared the timer cache and ran the command stsadm -o execadmsvcjobs Follow the article http://blogs.msdn.com/b/jamesway/archive/2011/05/23/sharepoint-2010-clearing-the-configuration-cache.aspx

4.Increased the connection time out from 120 secs to 240 secs.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.