[p4] Server performance questions.

Stephen Vance steve at vance.com
Fri Oct 19 07:04:37 PDT 2001

At 02:42 AM 10/19/2001 -0700, Russell C. Jackson wrote:
>Hi everyone,

Hi, Rusty!

>1. Has anyone else seen similar problems? If so, did you find a solution, or
>at least a cause?

Richard Baum just did a presentation on server performance issues at the 
conference.  It's not posted to the Perforce site yet, but some of the 
information comes from there.  Thanks Reb.

It sounds like you have some operations that are locking portions of the 
depot causing other operations to queue up under load.  Obliterate will do 
this, but I doubt you are doing that on a regular basis.  Review daemons 
are a likely source, as are what Richard calls "complex or confusing client 

For review daemons, they may be using Perforce operations that aren't 
optimized.  Perforce is fast, but not for all operations, and some 
operations by their nature require lots of CPU, network or locks.  Large 
syncs (build daemons?) or submits (auto-integrators?) and 'p4 verify' are 
resource-intensive.  You could break them up into a larger number of 
operations with smaller scope, or reduce their scope to only that necessary.

On client mappings, ensure that they are all one-to-one.

You can restart your server with logging level 1 or 2 to see details of the 
operations in progress.  This will allow you to correlate the start and end 
of operations in progress with the periods of unresponsiveness.

You can also have your users reduce or eliminate the auto-refresh interval 
in the GUI.

Also, make sure that it is really the Perforce process causing the problem 
and not competing processes, like virus scanners.

>2. If you have a similar, or larger size server:
>         A. What is your configuration?
>         B. How many users do you have remote?
>         C. How many of your users use the GUI?

My installation wouldn't help you much here.

>3. Do any of you have any recommendations about whether faster hardware is
>the way to go, or should we be looking into splitting this server into
>multiple smaller servers? Multiple smaller servers is a pain in terms of
>code management, server maintenance, and costs is why we have avoided going
>that route so far.

Determine the root cause.  The solutions will likely follow.  Lots of 
memory, fast disk and fast network, which you seem to have.

On the network front, is your entire network path gigabit or just the 
NIC?  How many switching layers between the client and server?  Are they 
switches or hubs?  What speed?  What duplex (should be answered by the 
switch/hub question, but some client NIC settings could impact)?

As always, check with Perforce support.

Stephen Vance
mailto:steve at vance.com

More information about the perforce-user mailing list