Sharepoint 2010 WebPart performance

Our SharePoint 2010 farm consist of 2 WFE's and 1 app server and a cluster DB. We had a MS Risk Assessment done a couple of months ago because of sharepoint farm is performing poorly. This was because the person who setup the farm originally knew even less than I do about sharepoint... ;-) The risk assessment point out that all of our physical server that run our sharepoint eniroment have more than enough resources to run our small environment.

All our are site use SSL and are load balance via a Citrix Netscaler.

I have been reading up on developer dashboard and have been testing this out in my lab. All of our site are very simple, so RSS feeds or streaming content. Uses use SharePoint to unload and download office and pdf files. Webparts are used to display / list documents and that it as far from what  I can tell yet all of the web parts seem to be custom built and not using any of the out-of -the-box web parts.

1) Is there a stadm command I can run to list all webpart in use by all sites in our environment and which site they are used on.

2) Am I correct the OOTB web parts would probably work better than custom?

3) I notice dour OnPreRender time is what seems to be slowing things down. What should be a simple web part the render time are 50 - 75 ms.

Also , we are already using IIS compression.

Stupid question, how can I tell the the difference between a custom and OOB web part when looking at developer dashboard?
LVL 20
Who is Participating?
1) use powershell, e.g.:
2) Depends on what they do.  They will use the same Sharepoint API but any wabparts taht are for example querying external datasources could be slow.

3) This doesn't seem unreasonable.

Custom webparts will have a non-microsoft namespace in their name (eg. Bamboo.webpart....)

If you are having performance issues try disabling the loopback check on your WFEs:

Also check servers are not generating lots of page faults, and the database is not a bottleneck.
compdigit44Author Commented:
I was just reading the compression is enabled by default in IIS but not configured. Is there a way to tell what the compression level is currently set at.
compdigit44Author Commented:
Thank you for your feedback. I will have to give this a try when I am back in the office Monday.

Do you have any thought on how to check my current cache level in IIS?
c:\Windows\System32\Inetsrv\appcmd.exe list config -section:httpcompression

Note this setting will only really affect users if your network is struggling.

You might also find it useful to look into using the Sharepoint Health Analyser:

Its also worthwhile to configure perfmon to look at what your servers are actually doing and where any bottlenecks may be occuring:
compdigit44Author Commented:
thank again for the feedback.

I have used the sharepoint health analyser along with the results from our Microsoft Risk Assessment an cleaned up a lot of items!!!

My questions for compression and web part tuning came from the suggestion in the following article.

I am not sure if this will help or not but we are not using a warm up script.

I will post my results of your suggestion shortly.
compdigit44Author Commented:
Ok here are my results..

1) I ran the script to list all web parts and it did run but did not return any results. Also I noticed that you need to list each site one-by-one I have tons of sites and there must be a way to have the script start at the top level site an drill down.

2) The loopback check entry is not even configured.

3) DB server is not being stressed

4) Current compression setting are as follows. I see nothing regarding the compression level
compdigit44Author Commented:
Should I schedule a task to recycle my app pools daily?
1) You can loop through sites and subsites in powershell - make sure the script is working on a site that has webparts and then I can show you examples of how to make it iterate over teh farm.  

2) Before you do this, try disabling the loopback check on your wfe.  Reset IIS and see if it has any effect (it has for me in the past).

3) Good

4) Try enabling it and setting to 6.  Also look into blob cacheing.

On app pools - only if it improves performances (i.e. try it and see what happens).  I think our app pools are set to recycle (you can configure this in IIS manager).

It might be worth you reading this:
compdigit44Author Commented:
Thanks for getting back to me.

1) In regarding to the script to list all web parts in the root site and all sub sites I am using the script in the link you posted earlier:

2) I miss read you initial post it sounds like starting in Windows 2003 loopback check is enabled by default... I will set this and let you know. Is a reboot required.

3) Glad DB is working well!!!

4) Since you are a SharePoint expert I was hoping to get your recommendation on app pool recycling. From what I have read IIS will recycle the app pools every 29 hours but is this inline with the best practices for SharePoint.

5) I downloaded a sharepoint warmup script from codeplex and tried it in my test environment and it really noticed a performance difference
You can runs that script against the root site collection and it should show all webparts used in that collection.  It will only show webparts used in pages in the "Site Pages" folder so if any are used outside of that its not going to show them.  

You would be better looking at what solutions (features) are deployed in central admin now I think about it - webparts will be deployed here and will tell you which sites they are deployed to.  You can find this by logging on to the app server (or wfe) and start up the central admin tool and navigate to: CEntral Admin->System Settings->Manage Farm Solutions

I'm not really sure what the best practice is re: apppool recycling - however due to the "Just In Time" nature of .Net it will impact performance as the cache will have to be rebuilt.  I have left mine at the default settings and never heard of anyone changing it.

You might like to read this for more info:

Warm up scripts etc will improve performance after a restart/recycle, but if your users are suffering from a general slowness not directly after a restart/recycle then it is probably something else.

Try disabling loopback, then look at enabling BLOB cacheing:

Also check you domain controllers are not causing a bottleneck (I can't offer any more advice about how to go about this, netwrking is not my area! :) )

Have you checked the ULS logs for anything unusual?   (warning - it is normal to get LOTS of logging information.  Look for "high" or above messages, and search to timeouts etc in the description text).  As you are using a farm you might want to merge your log files from each server into a single source (see:
compdigit44Author Commented:
Thanks for the tip about check the "Deployed Solutions" in Central Admin. I never thought of that and checking it now..

I do have a question regarding disabling loopback checking. From everything I have read this is usually disabled when users are getting a double login prompt which we are not getting. Please note we are using claim authentication but not using Kerbose but NTLM since our farm was never setup correctly. I am puzzled as to how this could help with performance.

I will post further results shortly.
I've noticed it made a difference on one of my own farms (using basic NTLM).  I honestly don't know why it improved performance but it really did (as already explained I am in no ways a network expert :) ).  In a farm environment you are relying on your network infrastructure being upto scratch (because operations are spread across the farm and the system is therefore constantly communcating between servers)  so if for any reason the network is problematic then that will show up as poor performace, despite the individual servers show little load.  This also applise to your security setup.

Its worth trying it out.  If it makes no difference put it back to how it was.

Also remember you cannot judge performance accurately until the system is warmed up :)

You might also want to extend a web app to use use NTLM/Kerberos security and compare this with your claims based web app - if it performs much quicker then perhaps that is an area for you investigate.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.