TFS 2008 – VM performance tweaks

I’ve been doing a few tweaks on our TFS 2008 VMWare VM recently to improve performance. We host both the application and data tiers on the same VM so we are never going to get blistering performance (especially when the host is essentially a desktop!)  but the performance through Team System Web Access (TSWA) has been noticeably clunky of late, so we thought a little tweaking was in order. Interestingly, source control through Visual Studio has been fine though.

Here’s the list of mods I did:

• changed the virtual disk (vmdk file) from variable to fixed size (in our case 80Gb). Although this uses more disk space on the host, allocating it all in advance provides better disk I/O performance. I simply used the command line tool vmware-vdiskmanager.exe with the –r and –t 2 switches.
• excluded antivirus scanning of the VM files on the host
• installed the latest VMWare Tools (take care, when I did this, upon reboot the drive letters D: (DVD) and E: (partition) switched, causing service failures at startup. Easy to fix but  something to watch out for)
• stopped any obvious unneeded services on both host and guest
• resized the partitions inside the guest to give the OS more breathing space
• defragged the guest and host disks
• disabled ‘shutdown worker processes after being idle for 20 mins’ option on the web app pools in IIS (see web app pool properties, performance tab). I left the recycling tab options at the default settings though.

Finally, I also set up WebWatchBot (a site monitor we use) to ping the key eScrum and TSWA TFS services we use with a http request every hour, to keep the old TFS ‘engine’ alive. As I’m sure everyone who uses TSWA will have noticed, there is a big start up cost on many of the functions if left dormant and any caching is lost, so pinging the box occasionally keeps it all alive, especially when TFS is under little/no usage periods. Of course, we also now have the additional benefit of knowing when TFS is down too ;-)

Lets see how it goes… I’ve not done any formal timings but the results so far (and comments from users) indicate a much more responsive system.

Clarkey