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.
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"