RE: Perfromance Issue in Customised Sharepoint 2010 Application

We are facing performance issue in our customised sharepoint 2010 application and for some of the users, session gets timed out in 5-10 minutes even though session timeout is set for 30 mins at IIS and network load balancer level.

During analysis we have come across below mentioned errors in event viewer and SharePoint logs.

Although we are trying to further investigate these issues, it would be great if you can help us out to investigate and resolve these issues.

1)      Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bd0eb

Faulting module name: OLEAUT32.dll, version: 6.1.7600.16872, time stamp: 0x4e588139

Exception code: 0x80000003

Fault offset: 0x0000000000001325

Faulting process id: 0x19f4

Faulting application start time: 0x01cf0c355034d80a

Faulting application path: c:\windows\system32\inetsrv\w3wp.exe

Faulting module path: C:\Windows\system32\OLEAUT32.dll

Report Id: 3f8c1091-782c-11e3-9b29-000c292a7603

 

2)      An unhandled win32 exception occurred in w3wp.exe [3180]. Just-In-Time debugging this exception failed with the following error: Debugger could not be started because no user is logged on. Check the documentation index for 'Just-in-time debugging, errors' for more information.

3)      Object Cache: The super user account utilized by the cache is not configured. This can increase the number of cache misses, which causes the page requests to consume unneccesary system resources. To configure the account use the following command 'stsadm -o setproperty -propertyname portalsuperuseraccount -propertyvalue account -url webappurl'. The account should be any account that has Full Control access to the SharePoint databases but is not an application pool account.

      Additional Data: Current default super user account: SHAREPOINT\system

4)      Exception from HRESULT: 0x80131904
5)      A process serving application pool 'SharePoint - XXXX' suffered a fatal communication error with the Windows Process Activation Service. The process id was '####'. The data field contains the error number
6)      Faulting application name: w3wp.exe, version: 7.5.7600.16385, time stamp: 0x4a5bd0eb

            Faulting module name: KERNELBASE.dll

7)      Cannot connect to SQL Server. XXXXX not found. Additional error information from SQL Server is included below.
            Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding

solution 1:

Looking at point 3 in the logs provided by you.

 

You can try doing the following steps

 

First create two normal user accounts in AD. These are not service accounts.

You could call them domain\superuser and domain\superreader

 

The domain\superuser account needs to have a User Policy set for that gives it Full Control to the entire web application. In order to do this you perform the following steps:

• Go to Central Administration
• Go to Application Management
• Go to Manage Web Application
• Select the web application we’re talking about
• Click User Policy
• Add Users
• Click Next
• Fill in domain\superuser
• Select Full Control
• Click OK

The domain\superreader account needs to have a User Policy set for that gives it Full Read to the entire web application. In order to do this you perform the following steps:

• Go to Central Administration
• Go to Application Management
• Go to Manage Web Application
• Select the web application we’re talking about
• Click User Policy
• Add Users
• Click Next
• Fill in domain\superreader
• Select Full Read
• Click OK

If your web application is using claims based authentication the users should be displayed like i:0#.w|domain\superuser and i:0#w|domain\superreader.

 

Also you have to assign values to the properties of the webapplication, for which you will need to execute the following commands in Windows PowerShell.

 

 If you are using classic mode authentication run the following cmdlets on one of your SharePoint servers:

 

$w = Get-SPWebApplication "http://<server>/" $w.Properties["portalsuperuseraccount"] = "domain\superuser" $w.Properties["portalsuperreaderaccount"] = "domain\superreader" $w.Update()

 

If you are using claims based authentication run these cmdlets on one of your SharePoint servers:

$w = Get-SPWebApplication "http://<server>/" $w.Properties["portalsuperuseraccount"] = "i:0#.w|domain\superuser" $w.Properties["portalsuperreaderaccount"] = "i:0#.w|domain\superreader" $w.Update()

 

After you've run these PowerShell cmdlets you need to perform an IISRESET to finish it off.