I’ve heard a few Administrators, and businesses as a matter of fact, stating that SharePoint is slow in some situations. Sometimes that slow performance is caused by a bad SharePoint Farm topology. I will not get into that in this post because what I will talk about here will not sort out that problem.
What I want to highlight here is about speeding up an already existing farm, that has no infrastructure bottlenecks, by using all the caching mechanisms avaible. We can fine-tune SharePoint performance in 3 different ways and we need to make sure each one of them has been properly configured/used in order to squeeze out the last SharePoint performance drop. See the list below:
1- Caching provided by SharePoint out of the box.
2- IIS Caching.
3- Dynamic caching from custom ASP.NET code.
Instead of explaining all the ins-and-outs of this interesting topic myself, I will just show a set of links where you can obtain all the information. I would be repeating 99.9% of content already published and I’m sure I would forget something important to close the loop. So… caching links… here they go!
1- SharePoint Caching… Cache settings operations
• BLOB cache
• Page output cache profiles
• Object cache
http://technet.microsoft.com/en-us/library/cc261797.aspx
• Monitoring SharePoint Caching performance
http://technet.microsoft.com/en-us/library/ff934623
2- IIS Caching… Configure cache settings for a Web application (SharePoint Server 2010)
http://technet.microsoft.com/en-us/library/cc770229
http://technet.microsoft.com/en-us/library/ee424404.aspx
3- Dynamic caching from custom code
• The ASP.NET Cache object allows you to store information in memory that requires expensive operations to create. Additionally, the Cache class is available to all Web Parts in a Web application so Web Parts on different pages have access to the cache.
http://msdn.microsoft.com/en-us/library/18c1wd61(v=vs.85)
• ASP.NET ViewState object. View state allows you to store values between post backs on a single page and cannot be used to share information between Web Parts on different pages.
http://msdn.microsoft.com/en-us/library/bb386448(v=vs.90).aspx
• ASP.NET SessionState object. Session state allows you to store session information that is tied to an individual user session. This does not allow the information retrieved from the Web service to be used when different people view the Web Part.
http://msdn.microsoft.com/en-us/library/87069683(v=vs.85)
• ASP.NET Request object. The Request object stores information about an individual HTTP request and is not accessible to subsequent requests to different pages.
http://msdn.microsoft.com/en-us/library/system.web.httprequest(v=vs.90).aspx
• ASP.NET Application State. Application state is a data repository available to all classes in an ASP.NET application. Application state is stored in memory on the server and is faster than storing and retrieving information in a database. Unlike session state, which is specific to a single user session, application state applies to all users and sessions. Therefore, application state is a useful place to store small amounts of often-used data that does not change from one user to another.
http://msdn.microsoft.com/en-us/library/ms178594.aspx
• .NET Singleton. The Singleton Design Pattern ensures that only a single instance of a given object can exist. It does this by making the class constructor private so that it [the singleton itself] has full control over when the class instance is created. In order to gain access to an instance of a class that implements the Singleton pattern, the developer must call a shared/static method of that Singleton class.
http://wiki.asp.net/page.aspx/288/singleton/
Albandrod's Memory 