[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