Late last year my colleagues and I tried to distil the tasks that impede SharePoint developer productivity. Then I ran those tests on EC2, Hyper-V and VMware Workstation, with the latter two virtualisation technologies running on a desktop, an older laptop and a newer laptop. In this post I hope to shed a bit of light on some follow-up testing that I’ve squeezed in to the odd hour here and there over the last six months. Unfortunately hardware availability and my schedule have not aligned to produce a further round of comprehensive tests and since I can’t see that occurring in the immediate future I’m going to fill in some gaps here with a couple of additional concrete findings, particularly regarding i5 vs. i7 testing and the impact of SSD on first page load times after application pool recycles. I’ll also talk less rigorously about a few related issues.
SharePoint 2010 Development Environment Performance: SSD, i5 vs. i7, WEI and Sandy Bridge
Hardware, Performance, SharePoint, Virtualisation, Windows | 
3 Comments »
People Search Result Organisation Browser Link Doesn’t Respect Alternate Access Mappings
My colleague Anthony Clegg and I have recently been working on a project together, for which I’ve designed and delivered the infrastructure, while he’s been delivering the solution. As part of my design, I extended the SharePoint Web Applications from the default HTTPS zones to new HTTP zones, exclusively for crawling. This approach has been around for some time, but there’s a new wrinkle on the SharePoint 2010 Enterprise Search Centre People Search results page, which I’ll discuss here:
Consultancy and Design, Performance, SharePoint | 4 Comments »
Office Web Apps Infrastructure Considerations
I’ve recently been involved in a somewhat unusual client engagement, in that I was designing and delivering the infrastructure without knowing the shape of the IA or solution architecture. Obviously, this imposed some restrictions on what we could define, but it also meant that I had to handle some aspects of the engagement that would normally be taken care of by other colleagues. To that end, I suppose some of these considerations aren’t purely infrastructure-specific, but they could be in an engagement like this one and they’re things that infrastructure people should understand. Hopefully it’ll be useful for solutions people as well.
Client applications, Consultancy and Design, Performance, Security, SharePoint | No Comments »
SharePoint 2010 Development Environment Performance Test Results
Drum roll please! At long last, I bring you the results of a great deal of testing. Here’s the background:
- SharePoint Development Productivity and Virtualisation Technologies
- SharePoint 2010 Development Environment Performance Tests
I’ve said my preamble in those posts, so I’ll cut to the chase here.
Hardware, Performance, SharePoint, Virtualisation, Windows | 6 Comments »
SharePoint 2010 Development Environment Performance Tests
As I indicated in my last post, I’ve been plundering the depths of SharePoint development productivity in recent months. Understanding the context established in that post is pretty essential to understanding what follows here. In a nutshell, I’m trying to improve system performance for current users of our SharePoint development environment. This is not as simple as examining the Windows Experience Index on a number of laptop models. I needed to consult with our users to identify which tasks are slow for them and devise tests that would allow me to measure system performance on different physical and virtual systems. In this post I will describe the systems, the tests and the testing process before reviewing the results.
The Tests
The 21 tests that we settled on were the result of discussions with a number of the core developers, consultants and architects at Content and Code, plus a few tests that I threw in to confirm/disconfirm some of my suppositions, such as the impact of the User Profile Service Connection on first page load time. All 21 tests were run three times for each permutation of hardware candidate and virtualisation technology. We also tested on Amazon EC2. I will discuss the testing process in more detail in a moment.
Hardware, Performance, SharePoint, Virtualisation, Windows | 3 Comments »
SharePoint Development Productivity and Virtualisation Technologies
In the near future, I’ll be discussing the results of the SharePoint Development productivity testing that I’ve been working on for some time. A key part of the background to that story is a choice to virtualise SharePoint, and within that, a choice of virtualisation technology. In this post I’ll be reviewing the problem in advance of a more detailed discussion of the productivity gains and losses with some of these technologies/approaches.
For clarity, I will quickly state the problem as I see it. SharePoint 2010 system requirements and practitioner mobility requirements are inherently at odds. What guidance exists for this unique problem space tends to regurgitate preferences/allegiances rather than comparing technologies and ratifying assumptions with real-world tests. At best, you get system performance indices for a single laptop model, but these results may vary when any hardware component is changed.
Performance, SharePoint, Virtualisation, Windows | 10 Comments »
User Profile Service Connection and Slow First Page Load
I’m presently running some quite methodical SharePoint 2010 development environment performance tests, as we’re finding that the Dell XPS M1330 we’ve been using for the last few years doesn’t really cut it in some scenarios. This has been an on-going issue for some time where I work, but it’s only recently been prioritised at the top of my workload. That it is now my top priority should give some indication how important these issues are for any company that spends significant time customising SharePoint. I’ll be discussing this wider project in more detail once I’ve finished my testing in the next couple of weeks, but for now I wanted to share a provisional finding about connecting Web Applications to the User Profile Service Application.
Bit Rate Throttling Fix Released
A couple of weeks ago I posted information about a Fix For Bit Rate Throttling W3WP Crashes in SharePoint 2010. A few hours ago, Jack Freelander from IIS.NET announced that IIS Media Services 4.0 has been released, including this fix. This is just a quick post to update that the fix has passed Beta, in case anyone was waiting on the final release before diving in.
I still have yet to find the time to test this myself, but I’d be very keen to hear about your experiences – good or bad. Failing that, I hope to get back to this in the next couple of weeks.
Networking, Performance, SharePoint, Windows | No Comments »
Fix For Bit Rate Throttling W3WP Crashes
Over the Summer, we dove deep in to SharePoint 2010 for WCM when we re-launched our corporate website. As I mentioned the other day, I spent a decent amount of time looking at caching and some of the new supporting technologies, like Bit Rate Throttling, an IIS.NET extension to IIS 7.x – part of the IIS Media Services 3.0. package that also includes Smooth Streaming. Bit Rate Throttling is like when you watch a YouTube clip and it only buffers a short time in advance of what you’re watching, also known as Progressive Download. In Microsoft’s words, Bit Rate Throttling is…
“…an IIS 7.0 extension that meters the download speeds of media file types and data between a server and a client computer. The encoded bit rates of media file types such as Windows Media Video (WMV), MPEG-4 (MP4), and Adobe Flash Video, are automatically detected, and the rate at which those files are delivered to the client over HTTP are controlled according to the Bit Rate Throttling configuration.”
It basically saves you bandwidth by only transferring what you’ve watched plus a small, configurable buffer. Think about each user that starts watching a ten minute video but only watches one minute. In that time, they may have downloaded five minutes of content – quadrupling the bandwidth consumption unnecessarily. Bit Rate Throttling shares some user experience characteristics with Streaming Media, but it works on a normal web server over HTTP. It’s really quite a simple tool and I won’t devote space here to explaining it when the IIS.NET site already has some great content, including a brief introductory video. Definitely check it out.
So why am I writing about it?
BLOB Cache, HTTP 304 Results and F5/Refresh
A few months ago we launched a new website on SharePoint 2010. One of my main foci on the project was performance and caching is one of the most effective ways to achieve that for a WCM solution. We enabled Output, Object and BLOB caching, configured exclusions as necessary and were quite pleased with the results, especially since issues with BLOB Caching in 2007 have been resolved in 2010.
A few weeks later I was demonstrating these approaches when it was pointed out that we were getting lots of 304 responses. They occurred with each request for a previously-downloaded BLOB Cached asset (more detail added below). Basically, I overlooked the max-age attribute in the BLOB Cache web.config settings. By default, this attribute isn’t present in the web.config file and I simply missed it. Adding this attribute eliminated the 304 results and the caching configuration was complete. Or so we thought.
Edit to provide more detail on the 304 status and Max-Age
A 304 response is a File Not Modified status (not an error), in this case indicating that the browser is making (potentially) surplus checks for each previously-downloaded BLOB Cached file. The max-age attribute gives the file a lifetime in the client’s browser cache in order to reduce these update checks. To be clear, the BLOB Cache stores large objects on web servers to reduce database traffic, but those objects can be served with a max-age attribute that will determine the object’s lifetime in the client’s browser cache. A max-age value of “14400″ means that browsers will cache the file for four hours before checking for an update. This means that updates to BLOB Cached content may become stale if this value is set too high. A common value would be “86400″ (24 hours) but we were satisfied with the balance at four hours. In our case, making this update has not yielded a perceptible increase in performance with the current levels of traffic, but it’s the sort of thing you want to set appropriately in order to optimise things and to allow the environment to scale.