This is a Python script (tested on Python 2.5, but 2.4 should work as well) script to monitor the
performance of a Windows Perforce server. Both client and server need to run on Windows XP / Server
2003 or later, and the server should be reachable over Windows networking. It uses the standard Windows
Typeperf tool to query performance counters on the server. This requires (Windows) admin access to the 
server. It also uses the Sysinternals (now Microsoft) tool PsList, which can currently be found at:
http://www.microsoft.com/technet/sysinternals/utilities/pslist.mspx
Just put pslist.exe next to the script, so it can find it. Also, make sure the other files from
this directory are present next to the script.

The Perforce server must have monitoring enabled, if necessary, turn monitoring on with:
p4 counter -f monitor 1
and restart the server. To get the most out of the script, Perforce admin access is also required. 
Specify the name of an admin account to use at the top of the script. If a password is required for 
this account and no valid ticket is present, the script will ask for the password at startup. 
If the admin login fails, the script will still run, but with less detailed output.

A good trick to get round the admin access, and also to enable monitoring a server that has become
(nearly) unresponsive, is the following:
- Run a second “monitoring” p4s on the server (on, say, port 1665), with it's own db directory.
- Delete the monitor.db of the second server, and replace it (using fsutil) by an NTFS hardlink to 
  the main server monitor.db.
- Now, running ‘p4 monitor’ on the second server will give you all the information from the main server 
  monitor.db, even if that one is completely unresponsive. An additional advantage is that, if we keep the 
  second server without an admin password (there is nothing of value in there, so this shouldn’t be a big 
  problem), monitoring scripts such as this one won’t need to mess around with admin passwords or 
  everlasting tickets

The script uses typeperf counters to get the server stats, these need to be configured
at the top of the script so that it will query the right disk and network interfaces. To get a full list
of available counters, do:
typeperf -qx \\server_name
The network interfaces can be found in the list as
\\server_name\Network Interface(NAME)\...
The NAME is what should be specified as the typeperf counter below.
Disk interfaces can be found as:
\\server_name\PhysicalDisk(NAME)\...
Figuring out which are the right interfaces isn't always easy, especially in a server with lots of disks
and network interfaces. Still, a bit of experimenting should give you the right ones. I've left some
sample values in the fields in the script so you know what sort of thing to look for.

The output should mostly be obvious: All sizes are in megabytes (MB), not bits. p4[s|d] memory usage is
shown as Virtual / Physical. If Virtual memory usage of p4s gets anywhere near the total amount of
physical memory, you're likely to run into lots of swapping and performance problems. P4 threads are
sorted according to the time they have been running, with the longest one at the top. Runtime is listed
as hh:mm:ss. Cpu % per thread is a % to total cpu available. So on (say) a 4 core machine, a single thread
can never use more than 25% of cpu and if that happens that thread has become cpu-bound. However, the Cpu %
for proxy / client are per Cpu (or core), so these can go to 100%. The Connection column can be useful to 
see if everybody is using the right proxy/server connection (in which case the Workspace column can help 
in determining where the query originated). Just what exactly the disk usage % means is a bit tricky to 
explain, but it is a reasonable indicator of disk usage. If it's 0%, nobody is using the disk at all, 
and if it's at 100%, the disk has become a bottleneck.

You can either run the script locally, or install it as a service on a webserver. The latter works best to
keep a constant watch on the server. Here's what you need to do to set this up:
- First of all, make sure the script is configured properly and outputs the html you want.
- Install the Win2K Resource Kit (or obtain srvany.exe and instsrv.exe from elsewhere)
- Install a p4mon service as follows (adjust paths as necessary):
  C:\Program Files\Resource Kit\instsrv p4mon "C:\Program Files\Resource Kit\srvany.exe"
- Check that p4mon is now listed as a Windows Service, and make sure that the Startup Type is automatic.
- Edit (or create, keys should be REG_SZ) the following registry entries, adjusting the paths as necessary.
  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\p4mon\Parameters]
  "Application"="C:\\Python25\\Python.exe"
  "AppParameters"="C:\\p4mon\\p4mon.py -o htdocs\\index.html -e address@host -m mailserver"
  "AppDirectory"="C:\\p4mon\\"
- In this example:
  C:\\p4mon\\               is the location of the the p4mon script.
  C:\\Python25\\Python.exe  is the path to the Python executable.
  htdocs\\index.html        is the path to the html file that will be output.
  address@host              is the email address that any exceptions will be mailed to.
  mailserver                is the name of the mailserver to use.
- Restart the p4mon service and verify that it generates the html output you want.
- Make sure the path to the generated html is reachable through the local webserver, open that path in 
  a webbrowser and enjoy your p4mon stats.

The end result is a webpage that you can easily consult to instantly see if the Perforce server is running
smoothly, or if it's in trouble, and, if so, give you some clues as to the cause of the trouble.

Please send any questions or comments to me: frank@compagner.com

Frank Compagner
September 21, 2007.