[p4] Quantitative data gathering to prove a thesis: Our clientspecs are too long.

Stephen Vance steve at vance.com
Tue Apr 30 11:06:13 PDT 2002


Identify which operations are slow and which are not.  Identify why (I 
suspect you already have) the client mappings need to be so complex.

Time similar commands using simple and complex client mappings.  As an 
example, turn a complex client mapping into a branch spec and a simple 
client mapping.  Integrate across the branch spec and perform the same 
operations against a client using the simple mapping from the branch.  This 
should give you identical numbers of files, etc.  Perform measurements when 
there is no other load on the server.  If this does not yield fruit, try 
concurrent tests and assess the performance under load and contention, but 
try to be the only one in control of the load.

Some alternative to complex clients can be: sub-dividing the depot along 
functional, product and project boundaries, using protections to hide 
unnecessary portions of the depot from groups, ensure that clients map only 
the portion of the depot necessary to establish their work context, 
branching to avoid complex clients, ensure that complex client maps are 
truly 1-to-1.

Run truss (Unix) on the p4d process, capturing child process activity as 
well, and look for contention and waits in the resulting system calls.

Use netstat, iostat, top and other performance tools to look at the various 
I/O, network, synchronization and utilization figures.

Take a look at Richard Baum's Server Swamp presentation 
(http://www.perforce.com/perforce/conf2001/index.html#swamp) from the last 
user conference for more diagnostic hints.

At 01:21 PM 4/30/2002 -0400, Chris Patti wrote:
>Folks;
>
>Due to some tools we're using here, our client specs are out of control 
>and we need a depot re-org badly.
>
>We're collecting evidence to try to 'sell' this to our developers, our 
>Perforce server is dog slow and we're hearing cascades of "Perforce 
>SUCKS!" from our unhappy userbase.
>
>So, does anyone have any suggestions on proving that part of our server 
>slowdown problem is crazily long clientspecs?  We have _quite a number_ of 
>clients in the 70-200 line range.
>
>Thanks!
>
>-Chris
>
>_______________________________________________
>perforce-user mailing list  -  perforce-user at perforce.com
>http://maillist.perforce.com/mailman/listinfo/perforce-user

Stephen Vance
mailto:steve at vance.com
http://www.vance.com/




More information about the perforce-user mailing list