SPRequest – things I couldn’t find about it

Since I’m doing more and more code reviews and trying to find where the performance issues are I’m noticing a lot of “bad performance” development.

Before reading anything more… Go and check your ULS logs on production.

Pay very close attention to errors like:

  • An SPRequest object was reclaimed by the garbage collector instead of being explicitly freed.
  • An SPRequest object was not disposed before the end of this thread.  To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it.
  • Potentially excessive number of SPRequest objects (30) currently unreleased on thread 16.
  • Detected use of SPRequest for previously closed SPWeb object.  Please close SPWeb objects when you are done with all objects obtained from them, but not before

Yes, these errors are not that good and are a good indication of performance issues.

First things first.. What is SPRequest? Well you can find more on this on the blog post of pavlov , it provides some interesting read.

Next up.. what is mostly the cause of these SPRequests?

Well this can be many things, creating too much SPSite objects in a short time will give you the excessive number of SPRequest objects warning.

But I will give you an example and tell me if it is wrong or not.

bad

Or

Good

Leaving out the fact that I’m using RunWithElevatedPrivileges or not.

So which one of the 2 will generate the  SPRequest errors?

The first one, why?

Because I’m creating SPSite and SPWeb , retrieving the SPList object and closing the SPSite and SPWeb objects, but continue to use the SPList object after the dispose of the parent.

The second is the one that is OK and doesn’t generate any SPRequest objects.

I’ve added a code sample that you can test, download here. Just deploy the visual webpart, hit the bad button a couple of times and meanwhile keep your eye on the ULS Logs via ULSViewer.

For 2013 you’ll see in the SPRequest warnings the following line:

To determine where this object was allocated, set Microsoft.SharePoint.Administration.SPWebService.ContentService.CollectSPRequestAllocationCallStacks = true. .

Now to set this to true (if it isn’t already set), you can use a simple Powershell script, I’ve used the one found here.

Than you’ll see the stack trace in those warnings.

Below is an example that I’ve received while hitting the “bad” button a couple of times.

14e8a1cc-d80a-4934-aec3-8acb9a0a9e61 Stack trace:    at

Microsoft.SharePoint.SPListItemCollection.EnsureListItemsData()     at

Microsoft.SharePoint.SPListItemCollection.GetEnumerator()     at

SPRequestDemo_2013.VisualWebPart1.VisualWebPart1UserControl.btn_GetlistBad_Click(Object sender, EventArgs e)     at

System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument)     at

System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     at

System.Web.UI.Page.ProcessRequest(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)     at

System.Web.UI.Page.ProcessRequest()     at

System.Web.UI.Page.ProcessRequest(HttpContext context)     at

ASP.WKPSTD_ASPX__1961116010.ProcessRequest(HttpContext context)     at

System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()     at

System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)     at

System.Web.HttpApplication.PipelineStepManager.ResumeSteps(Exception error)     at

System.Web.HttpApplication.BeginProcessRequestNotification(HttpContext context, AsyncCallback cb)     at

System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context)     at

System.Web.Hosting.PipelineRuntime.ProcessRequestNotificationHelper(IntPtr rootedObjectsPointer, IntPtr nativeRequestContext, IntPtr moduleData, Int32 flags)

You can see that somewhere in all the lines you’ll see SPRequestDemo…. well you can bet your money this is where the issue starts 🙂 .

I will post more example so that you can see how these issues happen. The first example is already provided and I used to write like that a couple of times myself (in the beginning 😉 ) .

Never think while writing I will fix that later, add a //TODO or fix it directly. It’s ok for just a few users, but when your solution is being used by 50.000 users this can have a serious effect.

If you want to read more about better SharePoint coding, below are a few links that are very interesting:

That’s all for now… happy reading

Leave a Reply

Your email address will not be published. Required fields are marked *