VSS Performance

VSS is not a true client/server system. All the VSS software runs on the client. No software component runs on the server. The VSS server is a giant shared file area. This means when you're concerned about performance you can treat the VSS server the same as you'd treat a file server. Monitor the same performance indicators, make the same tuning adjustments, and measure performance the same way. This is particularly helpful if you're asking some sort of "MIS" group that's not familiar with VSS to help maintain the system. You needn't set them up to run VSS or even mention VSS at all. Just ask them to treat the system like any other large file server.

Tune the VSS server for maximum file service. If your VSS server is using Windows NT Server, there are only a couple of parameters in the OS for this. The setting you reach through ControlPanel/Network[Services]Server>Properties...< presents the options "Minimize Memory Used", "Balance", "Maximize Throughput for File Sharing", and "Maximize Throughput for Network Applications". Choose "Maximize Throughput for File Sharing" (not Maximize Throughput for Network Applications"). You won't be able to reach this setting at all on Windows NT Workstation because one of the necessary buttons is grayed out. The foreground applications boost setting you reach through ControlPanel/System[Performance] presents a line with one end labelled "None", the other end labelled "Maximum", and an intermediate position. Choose "None" if possible. Or if some software such as your remote control application won't work right with this setting, choose the middle position. Any tuning hints for remote file service in the Microsoft Knowledge Base are useful more specifically for a VSS Server.

Try copying a very large (>1GB) file from a client to the VSS server and back. If it goes slowly, you have a way to illustrate the problem without involving VSS at all. Make the large file transfer faster, and you'll make VSS run faster too.

Use mondo hardware for your VSS Server, just as you would if it were a heavily used file server (which in fact it is).

Give the server a 100Mb NIC with a dedicated network line all the way to a main network "switch". And if the option is available make the network connection "full duplex". Don't allow any other system to share the network connection. Be sure the network "switch" never drops packets because of network congestion or any other reason.

The VSS server should have fast disks and a fast CPU. Look for both high transfer rate and low seek time in a disk. A fast CPU gets the data from the disk to the network quickly. If you store VSS files "compressed" on the disk, you need a fast CPU even more because the CPU has to do all the file decompression on the fly.

Also be sure there is plenty of RAM in the VSS server. RAM is relatively inexpensive; don't scrimp here. If you have too little RAM, the server will thrash itself to death and perform poorly. Beyond 80MB or so though NT doesn't seem to make use of the RAM no matter what you do. So start with 64MB, then add one pair of SIMMS and measure the difference.

Put the VSS database on a separate disk (or better yet a pair of mirrored disks) on a separate SCSI controller. The hardware I/O path for accessing the VSS database should be completely separate from the one for accessing the system and the swap file (probably on C:).

Consider placing user's SS.INI files on a different spindle or even on a different system. This will require modifying either the VSS Users_Path setting or the VSS file USERS.TXT or both. During operation VSS can be pretty "chatty" about reads of and updates to SS.INI, and these accesses can conflict with access to the data files.

In general VSS performance is insensitive to what's in the VSS database or how it's accessed or organized. There are some exceptions though. First, as noted by Microsoft, VSS performance is sensitive to the use of the "project rights" feature. If you don't really need "project rights", turn them off. And second, the VSS project tree should be "deep" rather than "broad".

Every time the VSS GUI redraws the top left pane that contains a tree of visible projects, it has to open and read a file for every project displayed to figure out whether or not it has subprojects. Projects with subprojects have a small box containing either a plus sign or a minus sign displayed just to their left. To figure out whether or not to draw this box, VSS has to look inside the file that defines the project. So if the list of projects is very "long" ("broad"), VSS has to look inside a lot of files.

This is probably most noticeable at startup time. If you have lots and lots of "top-level" projects that are visible when you first start VSS, there will be a noticeable delay between the time you launch VSS and the time the VSS GUI fully appears on your screen.

Microsoft makes quite a few recommendations about VSS performance in the documentation. Although you really should check the original documentation for yourself, here's a summary:

General Optimizations

Clear the box "Copy keyword-expanded files into working folder". Clearing this box may increase VSS' speed, as it tells VSS not to get a file after checkin. (If you have keyword expansion disabled for most file types anyway, this may have little or no effect.)

Choose to compare files by the "checksum" method. The "time" method may be even slightly faster, but it sometimes does not behave as you expect when you try to get earlier versions. The "complete" method degrades performance dramatically since it copies whole files just to do a comparison to find out whether or not it was really necessary to copy the whole file. You can safely rely on "checksum" comparisons. Fears that the checksum is too simplistic and different files could generate the same checksum appear ill-founded.

Specify a local folder (for example Temp_Path = c:\windows\temp) for temporary files. Do not just use the default setting, which stores temporary files on the VSS server. The location for the temporary files should begin with a drive letter; it should not be either a relative path or a UNC name.

Be sure the default Lock_Mode = Native is specified in SRCSAFE.INI. VSS supports an alternate lock mode in case the server does not implement native file locks correctly. But using the alternate lock mode degrades performance dramatically and is very seldom necessary. A test program for correct operation of native file locks is included with VSS.

Keep SS.INI files relatively short. If a lot of "cruft" builds up in this file, usually in the form of obsolete "working folder" settings, stop VSS and use an editor like Notepad to manually delete the unneeded lines from the file.

Other VSS Configuration Options

Set Diff_Ignore (PC) = c-e-s-w- to tell VSS not to worry about end-of-line differences when comparing files. The default behavior of ignoring end-of-line differences allows VSS to work in multi-OS environments, but may significantly slow file comparisons.

Users who are walking down "through" a project to get to a subproject should click on the box with the plus sign inside it, not on the name of the project. This will expand the list of subprojects in the left pane, without taking the time to refresh the right pane with information on every file in the project. If users can't remember to do this, you can "force" similar behavior by setting CP_OnSelection = No. With this setting, clicking on a project will not display the files in the project. With this setting, to make the project selection and display the files in that project users must explicitly press the Enter key.

Features To Disable

Each of the following features exacts a significant performance penalty. So turn these features off if you don't really need them:

• Shadow folders
• Journal files
• Project security system
• Keyword expansion

When walking down "through" the project hierarchy to get to a particular subproject, for each intermediate project click on the box with the plus sign inside it, not on the name of the project itself. This will expand the list of subprojects in the left pane, without taking the time to refresh the right pane with information on every file in the project.

Close up project hierarchies you aren't concerned with at the moment by clicking on the box with the minus sign inside it. VSS will repeatedly open every file in expanded portions of the project hierarchy even though you aren't doing anything in that part of the project hierarchy at the moment.

When you start VSS it will open the entire project hierarchy all the way down to whatever subproject was selected when you last exited VSS. So before you exit VSS, if you're fairly certain you won't be working on that subproject any further, click on a project higher in the hierarchy. This keeps VSS the next time you start it from expending time and effort to drill all the way down to a subproject you no longer care about.

VSS performs very well for the systems on a LAN and pretty well for systems connected by a WAN. But when some VSS users are connected by a telephone line, performance concerns are greatly amplified and special things have to be done. If VSS is to be used by remote users, there are three possibilities for what to do:

1. Take the network to the remote users. Make the VSS "file share" visible over the whole Internet. This will either make you paranoid, or get your VSS system hacked to death, or both.

2. Take the remote users to the network. Have the remote users connect to your internal network. You can do this either by having them dial in directly (you must provide a RAS server) or by having them dial in to an ISP then establish a Virtual Private Network link (you must provide a PPTP server). Most of the rest of this discussion focuses on this option. With this option, performance concerns narrow to the "slowest link in the chain", the telephone line connection.

3. Insert a "third tier" --an "applications server"-- between remote VSS users and the VSS database. You can simplistically think of this inserted system as a "staging" system. You will need some sort of third party software to do this. And in most cases your remote users will run some sort of VSS surrogate rather than the actual VSS client software.

If you have an almost-error-free line, VSS is quite usable anywhere above about 100Kb/s. If your ISDN connections run that fast and you still have problems, look for high error rates and either tune your network or kick your telecom provider. If the slowest link is slower than about 100KB/s, the VSS GUI becomes close to unusable even though the underlying functionality of VSS is working fine. This is equally true whether users directly dial in (probably with RAS) to the network where the VSS server is or dial in to an ISP then connect over the Internet (probably with PPTP). Remote users may have to resort to using the VSS Command Line interface instead, which is quite a bit faster than the GUI over a phone line. Another alternative is to work locally as much as possible and only resynch with the VSS repository once every few weeks. Yet another possibility is to have a "staging" system that's on the LAN that you drive with remote control software (like pcANYWHERE).

You may need to investigate various third party VSS Remote Access tools, several of which became available in the last half of calendar year 1998. Many of these tools seem to be variants of the "staging" system possibility that are specific to VSS rather than using generalized remote control software. Check out--

• GP-Version
• Source Off Site (same as CSFactory product; referenced by Microsoft)
• NetVSS
• Remote Visual Source Safe Server
• Gnome Hammer

You can minimize performance problems by clever configuration

• tell VSS not to re-get files just to expand keywords
• use compare-by-checksum as much as possible (especially use -GCK on command lines, as they may ignore the GUI comparison method setting)
• turn up TCP retry counts and turn down TCP timeouts

But you'll never make the VSS GUI really snappy over a telephone line.

What works best for our remote users using typical modem lines is to work locally as much as possible, then resynch with the VSS repository only occasionally, either expecting it to take all day or with a bunch of VSS command lines that run as an unattended batch job.

If you're looking for tight integration with Visual Studio, you may experience additional performance problems since the integration itself introduces a few problems over and above what VSS itself would have. In this situation, I recommend you investigate some add-on software called Gnome Hammer. Supposedly it makes the VSS integration perform fairly well over a dial-up line.

Here are some more tips for dial-in users to squeeze the most out of VSS.

Get a decent phone line. If you use TCP/IP, run the ping utility from the remote system to the VSS server. Packet loss rate should be low and response time fairly consistent. If only 80% of the expected responses make it back to the remote machine, somewhere the communications network is so bad that VSS will be unusable. Don't even try to use VSS until you have higher quality network connectivity.

Put an entry for the IPaddress of the VSS server in the HOSTS and LMHOSTS files, so the VSS client machine never has to send any hostname lookups to any other system no matter what. If the address isn't available locally, the remote system will have to send the request over the same telephone line it's using to talk with the VSS server. And some networking protocols --for example TCP/IP-- double-check network addresses as part of their error recovery process. So if the line is bad and there are lots of errors, TCP/IP will send an extra name lookup request over the line, making a bad situation even worse. Having local HOSTS and LMHOSTS entries for the VSS server prevents this particular vicious circle.

Move the SS.INI file to the local machine, so accesses to it don't go over the phone line. LAN-connected VSS clients should keep SS.INI files on some shared network server (not necessarily the VSS server) so they can connect from different machines and still get the same VSS options. But for dial-up users accessing the SS.INI file over the phone line so noticeably degrades VSS performance that the extra convenience isn't worth it. VSS refers to the SS.INI file all the time, not just at startup. For example every time you change projects VSS looks up any previous "working folder" setting. And every time you do a recursive operation, VSS looks for "cloaked" subprojects.