Understand database mirroring requirements for disaster recovery purpose

SharePoint 2010 is mirroring aware and utilizes the FailoverPartner keyword in its database connection strings to identify a SQL Server instance that is used for mirroring purposes.  Upon learning this, it might be tempting to jump right in and start mirroring SharePoint databases for redundancy.  Before doing so, though, you should be aware that the following requirements apply:

• Less than 1ms latency between principal and mirror SQL Server instances
• 1GB/s bandwidth or greater between principal and mirror SQL Server instances
• Principal and mirror instances must be running the same version and edition of SQL Server
• Mirrored databases must use the Full recovery model
• High safety with automatic failover (that is, synchronous mirroring with witness server) is recommended

Mirroring is certainly useful, but as the aforementioned list demonstrates: it shouldn’t be implemented without careful planning and infrastructure design.

KPI Values in SharePoint

Previous versions of SharePoint had limitations to folders support for the KPI Lists. Whenever you tried to set Folder as a source of your KPI, SharePoint gave you an error that the folder can't be selected. To avoid such situation you had to maintain KPI values in different list or use Views. The issue with Views is that they don't allow you to assign the permissions per View, so you can't have groups of data and assign different permission for KPI values based on views. The only solution for SharePoint 2007 was usage of separate Lists. SharePoint 2010 fixed this issue, and now you can organize your values per folders in one List for KPI’s.

SharePoint BLOB Caching to increase performance

BLOB caching, or disk-based caching, is an out of the box (OOTB) caching mechanism that is built into the MOSS 2007 and SharePoint Server 2010 platforms. It is commonly used to speed-up access to large and relatively static resources that are stored in content databases, such as images, videos, javascript files, and more. Performance improvements are gained by storing these assets on web front-ends (WFEs) once they’ve been requested by a client. This allows SharePoint to serve subsequent requests for such assets directly from WFEs instead of round-tripping to the content database each time a request for such an asset is received. For most SharePoint sites, this type of caching can significantly lighten the load on your SQL Servers and back-end network.

BLOB Caching is controlled through the web.config file for each of the IIS web sites that is associated with a Web application, and it is not enabled by default. Enabling BLOB caching is as simple as setting the enabled attribute to true in the web.config element as shown below.
  BlobCache location=”C:\blobCache” path=”\.(gif|jpg|png|css|js)$” maxSize=”10” enabled=”true” />