Readers Guide to the SharePoint Scalability White Paper

A SharePoint Server 2007 Scalability and Performance whitepaper was recently released "to provide strategic information about designing a high-volume, high-availability enterprise solution that can easily grow." it was announced yesterday in the SharePoint Product Team blog.

 

There is plenty of good content here, lots of good ideas, and many attractive diagrams. As for the tests, these are idyllic goals to shoot for if you want great performance – minimize (or eliminate) inserts and deletes, keep fewer than 200 files per folder (if you do the math, they appear to cap it at 130), don’t use more than 5 WFEs, and spread your databases over many physical volumes.  

 

Note that the testers assign 2 (or 3 in the case of H:) business divisions, each with its own content database, per 1 TB physical volume (Fig. 12), which is more SAN management than most shops are aware they should provide. This allows ~500 GB per division. It’s interesting that while the content databases stay under 200 GB for a combined total of <400GB, the used disk space averages 600.375 GB (Fig. 19). 

To restate the point: separate physical disks remain the best path to efficient I/O, and sets of local disks kick the tar out of any SAN that doesn’t take the separation into account.  Just because you move “the storage problem” to a network service doesn’t mean you should forget about intelligent design. The best practice to provide separate physical volumes for the OS, data, logs and temporary files remains.  

On to the test methodology. Note that in these tests they loaded the data beforehand, and the “user load testing” consisted of modifying existing documents, not inserts or deletes. No files, sites or site collections were created or harmed in the course of this study. Search the document for “delete,” you won’t find it. Why not? Because for each content database, list items inserts are O(n), and site creation and and deletion are (politely) non-deterministic. It takes an incrementally longer period to insert an item as it did for previous items. When the icon is spinning during site creation, other requests may (or may not) be fulfilled until the operation is complete. Deleting a site may also have an effect on response time. Again, this performance factor affects requests being served from the same content database, requests served by other content dbs are not affected.

Conclusion

For constructing a document repository with relatively static content, or a Publishing Site for WCM, this is an excellent and thorough document. This whitepaper describes a "large-scale content storage scenario" rather than a "large scale collaboration scenario." That doesn't mean you cannot build a scalable SharePoint collaboration environment, but this whitepaper does not claim to describe it. Keep that in mind when you look at the performance graphs. As to the architecture itself and the guidance provided in constructing the test farms, this whitepaper is worth a look. Thank-you to the team who put it together, there's some good stuff here, but for the future I'd really like to see testing go beyond browsing, search, and file updates. 

 

[Update 2009-09-05] Changed title from "Review of the SPSWP" to "Readers Guide to the SPSWP"

No Comments