This weekend I attended SharePoint Saturday Adelaide and picked up some handy tips and tricks from the following sessions:
Understanding SharePoint 2010 databases and storage – Alexandre Bacchin
Key databases to isolate and monitor:
- Usage and logging (write heavy)
- Search property store (ready heavy)
- Web analytics and reporting (can become large with heavy usage)
- Content databases – best to separate collaboration/intranet/My Site/management board. (I normally have a 1:1 mapping for collaboration and intranet site collections to content databases).
Other topics covered were:
- RBS (Remote Blob Storage) and disaster recovery
- Content databases should be maximum of 200GB (SQL database + RBS), not 200GB + RBS. The bottleneck is the number of list items in the database, not the blob size. With many list items, the list item table locks increase response time for users.
- High availability and disaster recovery though SQL clustering and mirroring.
- Optimise tempdb by using the fastest storage available.
- Set MAXDOP=1. SharePoint queries aren’t processing large datasets in a single query (like a data warehouse), so using parallelism over multiple CPU’s creates more overhead than executing on a single CPU.
- Run regular maintenance plans.
- Monitor growth of content and search databases.
- Set a restore plan and strategy (NOT JUST A BACKUP PLAN).
- Use SIMPLE recovery for dev and test environments. It uses less space (no log file) which increases in size quickly when constantly restoring sites.
- Change any of the SharePoint database schemas (SharePoint checks, plus it will void your warranty ).
- Change database file groups (leave it up to the DBAs).
- Let other applications access SharePoint databases directly. (Bad for security and may have issues with locks). Use one of the proper APIs instead.
- Never shrink content databases.
- Use RBS to get around the 200GB limit.
A great introduction to improving performance and diagnosing issues with server side page rendering times with the emphasis on publishing sites and custom code.
- Developer Dashboard + Developer Dashboard Visualizer from CodePlex
- SPMonitoredScope and SPCriticalTraceCounter.
- Object, BLOB and Output Caching.
- Alternate cross site/list query methods (Search, SPListItems GetDataTable, PortalSiteMapProvider, Content Iterator) to a foreach of SPList.Items. This will reduce memory, get around throttling limits and return data faster even though it might not be full up to date. See Microsoft’s White Paper: Working with large lists in Office SharePoint® Server 2007 for details.
- Disposing of objects + help from SPDisposeCheck.
- Location of site assets affects to max-age HTTP header and client/proxy caching.
New for me:
- Object cache multiplier.
- An SPRequest object is 1:1 with a SQL connection.
- SharePoint returns a health score for the current WFE to let the client know how much load the farm is on. It also disables certain features under heavy load (eg InfoPath Forms Services). It returns the HTTP header X-SharePointHealthScore in the range of 0 to 10, with 0 being least amount of load. SharePoint Workspace uses this score to determine how aggressively to synchronise content to the client.
The complete slide deck is available.
Brian used a video sharing site example to show how to use out of the box components and functionality, to write code, but less of it.
I was paying too much attention to take many notes, but the overview is available.
- Remember the user experience!!!!
- Try and make custom solutions look and feel like out of the box SharePoint.
- Instead of hand crafting an HTML table, use the InputFormSection control which SharePoint uses for its pages.
- Yes, the Tags & Notes button is broken, you need to mouseover it to make it appear pink (indicating there are existing notes or tags).
- I am going to use the buttons on the ribbon in a solution I am currently working on.