Print | posted on Monday, February 08, 2010 4:50 AM
Whilst I was one of the most vocal advocates for the ability to run SharePoint Server on the client OS, it wasn’t really something I ever thought I’d want to run myself. I understood why it was of critical importance to enable this scenario, but I’m a farm guy, topologies are my bag. When the beta release came about I slapped it on a old machine just to see it working and left it at that. I also checked out the quality documentation over on MSDN which provides the convoluted steps to get it singing. Such steps are a good thing, you need to really want to install it on your client – no one can say that it will get installed by accident. :) So it’s all good and that’s that, I’ll carry on doing my stuff as I was. Or so I thought.
Like everyone else, I’ve been heads down trying to get up to speed with all the new SharePoint PowerShell cmdlets, and revitalising my long lost shell scripting prowess (that’s a joke by the way, those who worked with me back in 1998 know the score!). The trouble is when I’m working away on documentation or in email (or worse, Visio and PowerPoint) or helping folks out on IM, I don’t want to have to load up a VM just to verify some scripts. Sure I can use the excellent references, but I like to test things actually work (no really). Running SharePoint on Windows 7 is a great way to do this without the burden and delay of firing up a VM or a bunch of them.
Recently there’s been a bit of debate about the pros/cons of running it on the client OS. All good stuff, but the common complaint is that it’s just too much overhead, it’s too bloated and is too resource hungry. Part of the problem is that it installs in the deadly “Standalone” mode. Standalone mode installs everything, lock stock and two smoking barrels plus uses a bundled version of SQL Express. There are ways to get it up and running in “Farm” mode, which I won’t detail here. If you want to run in a real Farm mode you should be on a real server OS IMO. I know some folks like ‘proper’ SQL and all that, but one of the key reasons for having a client install option is to lower the barrier to entry.
Which brings me back to the main point of this article. I’ve an old (in computer terms) Sony Vaio with 4Gb RAM and a Core Duo. Sony steals 0.81Gb of the RAM for nefarious purposes. A pretty low spec laptop, and one which is probably pretty common out there in the real world. It’s very easy as a grossly overpaid SharePoint person to slip into assuming that an 8Gb laptop is a ‘minimum’ setup. The reality is I’m lucky and can afford decent kit. There are millions of developers that don’t have such luxury.
So back to my crappy laptop. Remember the 3.19 Gb RAM I have available? Well I’ve got it running happily on that no problem. Very happily indeed as it turns out. I’m just using one Web Application and it’s very, very responsive. Certainly good enough for playing around and getting up to speed. With the application pools and services spun up Task Manager shows 70% of RAM used (that’s just 2.18Gb).
The thing is standalone provisions every service, and you really don’t need them! By judicious use of Services on Server you can tweak things very easily to have SharePoint 2010 running real nice. For example, how likely is it you wish to use the Document Conversions Service? No, I didn’t think so! :)
Here are the services I have stopped in Services On Server:
- Claims to Windows Token Service
- Document Conversions Launcher Service
- Document Conversions Load Balancer Service
- Microsoft SharePoint Foundation Incoming Email
- Microsoft SharePoint Foundation User Code Service (Sandbox Solutions)
- SharePoint Foundation Search
- User Profile Synchronization Service (this one isn’t provisioned by the Standalone setup)
- Web Analytics Data Processing Service
- Web Analytics Web Service
Note: to run elements of Central Administration such as Services on Server that make machine changes you must be running the browser instance as a machine administrator (UAC elevation).
Now of course you may wish to use some of these services, especially User Code. But you can simply enable them for the scenario you are working on and perhaps stop some others. The point is you don’t necessarily need them all running all the time. Web Analytics is definitely one you don’t want running on a hack and slash box, this is a real resource hog.
Another tip to improve performance for this scenario is to ratchet back the Diagnostic Logging levels and disable Usage Data Collection & Health Data Collection (both from Configure web analytics and health data collection). This will help reduce contention on the SQL Express instance and file I/O significantly. Of course should you get into debugging you will need to fiddle with the diagnostic logging levels some, but why log stuff until you need to? Health Analyzer will moan about things not being configured but so what? It’s a hack and slash box! You could even disable that timer job as well.
Now, the setup I have isn’t running SharePoint Designer or Visual Studio yet (I will try that next), and of course if Outlook (or worse Tweetdeck) is open, things get very dicey, but my key point is that SharePoint 2010 on Windows 7 performs a lot better than it’s being given credit for. It’s all about platform hygiene at the end of the day, if you manage your box you will be rewarded. If I had all 4Gb in this machine I could easily have a couple Office apps up and running alongside it no problem at all.
Back in the day with Site Server and CMS I always used batch files to stop and start the relevant services when I needed SS and/or CMS up and when I didn’t. You can do the same thing for SharePoint 2010 with Emmanuel Bergerat’s excellent Stop and Go PowerShell scripts.
There you have it, some fairly basic tips and tricks for getting great performance from SharePoint 2010 on your Windows 7 machine even with limited hardware resources. I may follow up with more on this in the future, but there are so many interesting topics and such little time…
Oh and on another note, did you see that 74 yard interception touchdown? Hoo ya! Red beans and ricely yours.