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.
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.
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 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.
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.
Recently we’ve been considering a hardware refresh for our developer/consultant/architect laptop build (on Windows Server 2008 R2 Standard with Hyper-V). After a fair amount of deliberation we decided to pilot a new model but stumbled massively at the first hurdle: when we enabled the Hyper-V role on a new Dell Latitude E6410 we got a blue screen. Further testing revealed that the graphics driver was at fault and the SVGA driver worked fine. However, the SVGA driver only has single monitor support. Back to the drawing board.
Continuing on from Part 1, in this post I’ll discuss the Microsoft 2010 Information Worker Demo Exchange VM, the SahrePoint VM’s event logs and potential future improvements to the environment.
Exchange Server Reconfiguration
Tidying up the Exchange server is a much more straight-forward process. In fact, all of the changes that I made are network orientated per the network changes from the first post, so if you are not adding a second NIC or a second fixed IP address on the original internal NIC, these steps aren’t necessary.
Continue reading “Optimising the SharePoint 2010 IW Demo VM Part 2”
Around the time that Microsoft released the public beta of SharePoint 2010 they also released a demonstration virtual machine, known as the 2010 Information Worker Virtual Machine, which was updated to RTM in mid-June. This is a fantastic resource for demonstrating SharePoint 2010. The content and demonstration scenarios (including walk-throughs) represent a huge investment from Microsoft and it would be foolish not to at least evaluate these assets. Personally, I think it’s silly to reinvent this wheel.
Now the public beta trial is expiring and people are moving to the RTM build. It appears to be much improved, in that more of the product works in this version and a few niggles have been fixed now. However, it’s widely acknowledged that the resource requirements for this virtual machine are gargantuan due to the breadth of what it offers.
Continue reading “Optimising the SharePoint 2010 IW Demo VM Part 1”
I’ve just finished watching Virtual PC Guy’s TechEd video on the forthcoming Dynamic Memory update for Hyper-V in Windows Server 2008 R2 SP1. The beta release of the service pack is due in July. The video is fairly lengthy, at around 80 minutes, but is well worth a watch if you’re interested and find the time. If not, here’s a round-up: Continue reading “Dynamic Memory for Hyper-V in Windows Server 2008 R2 SP1”
I was recently working with a Hyper-V VM that had a large branch of snapshots that I wanted to clean up, in order to conserve disk space. This was a SharePoint 2010 development VM which I’d configured specifically for a project, so I didn’t need all of the earlier snapshots. The environment has two VMs (one domain controller, everything else on the other), so I deleted all of the snapshots that I needed to get rid of on the first VM, one-by-one. From previous experience I knew that I could delete multiple snapshots before the initial merge operation completed. Hyper-V creates a queue of the merge operations that need to complete before the virtual machine can be restarted again. I left myself with only the latest snapshot and moved on to the second virtual machine to do the same. At this point I got a little too clever and started deleting the second snapshot before the first snapshot deletion was queued. It usually only takes a few seconds to complete but I jumped the gun and Hyper-V Manager threw two errors (4096 and 16410) regarding Virtual Machine file access when I tried to delete the second snapshot.
Cloning isolated VMs vs. scripted installation
One of the challenges we’ve always faced with SharePoint development has been the tension between cloning actually identical environments versus automating the deployment across distinct environments (or worse, repeating the installation manually). In the first case we save time by eliminating reconfiguration and this ensures a consistent experience for each user. This is particularly beneficial for software development. These benefits can also be obtained by scripting installation/configuration/deployment but there’s a considerable overhead associated with developing and testing those scripts. As SharePoint 2010 is still quite new and we’ve been working on projects for some time now, we didn’t have the luxury of waiting for those refinements and we needed to take advantage of these efficiencies as we had done with SharePoint 2007 projects.