I saw a post that referred to a document I hadn't seen. I then looked on the SharePoint Team site and didn't see it referred to. Looks like Microsoft IT (IT Showcase) rolled this out without much fanfare... Not sure if it's simply brand spanking new or what... This is a paper I was trying to fund back when I was at MS. It's cool to finally see it has hit the field. I want to give the IT guys a high 5.
I give this paper 5 stars out of 5. Could be more technical, but it might reduce the broader audience and readability. It's a great read, it's not high level, although it does spend a tiny bit of time in the features rather than prescriptive guidance, I was pretty impressed by the originality of the content. Sure some of it is a rehash of what we know, but also a majority of good content. There is a huge section on best practices... and by the way I saw the 3000 item reference
has already set of at least one blogger who has been living the 2000 item mantra. I've told people these list scale limits are not a cliff,
simply a guideline. Simply because it wants to chase it a little further shouldn't suprise anyone. I recently posted a Revisiting SharePoint List Scalability
due to the focus in this area. It's just the hottest issue these days. It's not a cliff remember that. Numbers of individual ACLed users, now there's a cliff. Keep that low...
Numbers of items turns into... What are you looking for 5 seconds, 7 seconds, or 20 seconds.... you have to decide. It's about wait time, render time, and something else you'll find in that doc... BLOCKING!!! Yep, one of my favorite IT topics that people don't get is covered in there. You have to read the section on SQL Locking/Blocking. It's good stuff. It will really help you get the right perspective on how to get a handle on managing this beast. Notice there's no stored proc optimization. Sorry SQL Fans.
Here's a quote from the paper:
"One persistent occurrence was SQL Server blocking, which the SharePoint Operations team assumed was caused by the SQL Server configuration. Yet, after many configuration changes such as mitigating large sites and lists, SQL Server blocking persisted. The SharePoint Operations team investigated both upstream and downstream causes of SQL Server blocking from the beginning. Separating self-provisioned team sites and personal employee sites into individual farms helped to achieve better tracking of statistics, yet both farms shared the same SQL Server storage subsystem. By looking further upstream during Phase 3, the SharePoint Operations team realized that the SQL Server configuration was not the chief root cause—the underlying network was. Specifically, the NIC configuration prevented delivery of the SQL Server payload to clients because the single NIC card could not handle the traffic volume and created congestion.
After reconfiguring the NICs on front-end servers, the SharePoint Operations team noticed a dramatic decrease in SQL Server blocking"
There are also good global deployment references including the tools they used with a snippet of code at the end of the paper. Good stuff.
I do recommend this as a MUST Read, and I'm adding this to my key performance and capacity planning documents.
Great writer, and great contributors... looks like this was a good mix... do it again on Microsoft SharePoint Service offerings/governance, another level deeper on usage... like how to determine load and give us the screenshots results of your fiddler sessions and narrowing down the problem troubleshooting steps. Virtualization definitely needs more focus. Isn't IT doing anything in this area? I know they are in dev and test... please share :) How about the steps you used for setting up NLB in the front end and back end NIC and how you teach the ops guys how to manage those static routes or if you're actually giving those different VLANs. Real OLAs and SLAs would be awesome as well. The MOF references were great. The structure and process starts showing... that's good. Oh and yes, by the way these comments are for IT Showcase... If you need feedback on what to write on next I've got a few ideas for you... Oh, and by the way, don't forget to say why, on some of the configuration items... like why 3000 vs. 2000 in a folder. I'm sure that's killing some people.
Great job everyone...