As a fan of NHRA, I’m going through withdrawal while waiting for the start of the 2010 season. I guess when you’re hungry, everything looks like food so SharePoint is beginning to look like racing to me. As I mentioned last week, I’ve lived my systems development career by the mantra “make it work, make it fast, make it pretty.” What I didn’t mention is that back in the early days of my career, “make it pretty” was in second place. That’s because making things fast in the days of 286 computers was expensive and usually involved rewriting some bit of code in C. Why did I switch the order around? I believe fast is more important today, especially for SharePoint, and pretty, well, pretty is in the eye of the beholder.
Why is speed so important for SharePoint? Because SharePoint is web-based! Regardless of what you are offering on your SharePoint server, the response time of that server is being compared to Google, or eBay or whatever page your users put up as the unattainable benchmark of speed. If someone searches for a document in SharePoint, they are mentally running comparative stopwatches with SharePoint and Bing. It’s OK if you’re slower but it’s bad if you’re SLOW. Unfortunately, making computers faster is like making cars faster; it is a matter of how much speed you can afford. Tim Wilkerson’s Top Fuel Funny Car (uppermost in the photo above) is one of the fastest cars on the planet, able to exceed 300 mph in just over four seconds. Tim understands the cost of speed, yet he does a masterful job of hanging in with big-budget operations by coaxing performance out of that car. That’s what we have to do in our small SharePoint shop.
The first place I look to improve the speed of SharePoint is in the way SharePoint is organized. Wait, isn’t that where I go to “make it work”? Yes, but if servers and sites are well organized, and well designed, people simply find the stuff they’re looking for, they don’t have to search and they don’t have to navigate through a lot of page-views. For example, if your document organization mirrors your ECM Classification Scheme, documents are easy to find. If users can navigate down a tree-structure as opposed to launching a search at a high level, you win.
If our users need to search, we want to make those searches faster. Metadata columns that are meaningful, and easy to complete when documents are uploaded, improve the performance of those searches. We are also reorganizing SharePoint, now that we know where the growth will be, to let us further distribute content among content databases. Effective use of content databases improves performance, and it also helps avoid some performance problems. Search scopes are also important, but unfortunately they are like the Advanced Search options in Google – most people don’t use them.
Hardware – this is where I really feel like Team Wilkerson
. There are lots of configuration, server and storage options we can consider to make SharePoint faster, but we’re small and on a pretty tight budget. On the other hand, we do consider performance with every bit of hardware we buy. For example, we recently replaced our storage array and we opted for SAS
drives instead of the less expensive SATA drives. SAS drives also have dual ports for redundancy which goes toward our goal of “make it work”. Last year, when we upgraded to SQL Server 2008, we brought in a new box with Windows Server 2008 because SQL Server 2008 and Windows Server 2008 run very well together. We also recently increased our Internet bandwidth so our customers and business partners don’t see our site as “one of the slowest sites” they visit. Tim doesn’t have to win every race, but he has to win rounds at each race. We don’t have to be the fastest URL in our users’ bookmarks, but we have to be among the ones they consider to be fast enough.
Next week, we will be looking at the “Make it Pretty” leg of my mantra. I can’t compare myself to Tim when it comes to appearance, he drives one sharp looking race car. Since this series started with a discussion on LinkedIn, I think it’s fitting that I have some company on the “branding” segment. Toward that end, Adam Levithan
, will also be blogging about branding. As for me, I’m going to turn SharePoint Stories over to Owen Baern, a Web Developer with AECOM. I’ll be introducing Owen later this week in a rare mid-week update for this blog. Owen has an interesting perspective on branding, and I look forward to having him share it here.
By the way, if you want to know more about the fastest sport on the planet, check out the Team Wilkerson blog