[p4] Performance impact of "large" clients

Anders Kjærgaard Hansen ANH at etiglobal.net
Thu Aug 6 22:50:49 PDT 2009

I totally agree. 

The ignored best practice, and risk of making errors, unintended submits, is the biggest problem. 

We do have a tool that helps our users create their clients, and that tool create clients per branch. So, if a product has main, some devel branches and some release branches, the client generated by our tool is only for e.g. the main branch of that product. 

And ~97% of our users use these clients as they are supposed to do. 

Our challenge is the last few users, which are competent enough to figure out how they alter the generated clients (or create new ones by hand), but apparently not competent enough to understand the possible pitfalls of using the large scoped clients spanning several branches. 

We have tried the educational way. 

And what I wanted from this thread was to gain some technical arguments that might convince them that they are actually disturbing the other developers by locking the database. Besides running the risk of submitting/changing files unintended as Ines examples showed.

"Luckily" some of the worst of our users are database developers, and the argument with database locking might actually be something they can understand. :-) Thanks to Jeff for that explanation.

Thank you all for your replies. I will head back to those developers trying to convince them why clients spanning the entire depot are BAD. 

For the record, I think we might combine our educational effort with some form-out, form-in triggers on client. 

Especially a form-out trigger that changes default clients to span over //depot/sandbox/main/... instead of //depot/...

Not quite sure yet if we create a form-in trigger, the disallows these clients, or if we just react upon it if someone creates a client we don't like.

Once again, thanks for the replies. I good first experience with the p4 mail lists. :-)

Best regards

-----Original Message-----
From: perforce-user-bounces at perforce.com [mailto:perforce-user-bounces at perforce.com] On Behalf Of Ines Heinz
Sent: Thursday, August 06, 2009 5:47 PM
To: 'perforce-user at perforce.com'
Cc: 'perforce-user at perforce.com'
Subject: Re: [p4] Performance impact of "large" clients

When we have allowed the code developers to have 
clients  that contain multiple branches, they
have not only done what Steve stated, but they 
also have mistakenly submitted changes for work
that had not been tested and reviewed.  Yes, you 
can put in triggers to help limit the pain, but
going for the simpler solution and having a 
client per branch is far safer and easier.

===========================Here is the scenario============================
I go into winedev and p4 edit the wine.atd file 
because my wine label is the up and coming one --
with the really witty comments about nuttiness and hints of berry.

Then someone realizes that the wine label in 
2009kegs has a misspelling of the word blackberry,
so I go and do a quick edit of that, get my edit 
reviewed and submit.  All well and good with
separate clients, but with a wide-open client, I 
accidentally submit all my opened files -- which
submits my witty comments (some of which had not 
been spell-checked)  into the winedev
branch without the appropriate review.

=====================wide open client=====================================
Client Root: /home/ines/perforce
Client View:
//depot/winedev/... //ines_perforce_workspace_for_updating_docsn/winedev/...
//depot/2009kegs/...  //ines_perforce_workspace_for_updating_docs/2009kegs/...

         cd /home/ines/perforce/winedev
         p4 edit wine.atd
         cd /home/ines/perforce/2009kegs
         p4 edit wine.atd
         p4 submit -d "quick edit to fix typo in 
blackberry"  #oops -- winedev/wine.atd is submitted!

=====================separate clients=====================================
Client Root: /home/ines/perforce/winedev
Client View:
//depot/winedev/... //ines_perforce_workspace_for_updating_docs_dev/...
Client Root: /home/ines/perforce/2009kegs
Client View:
//depot/2009kegs/...  //ines_perforce_workspace_for_updating_docs_2009/...

         cd /home/ines/perforce/winedev
         p4 edit wine.atd
         cd /home/ines/perforce/2009kegs
         p4 edit wine.atd
         p4 submit -d "quick edit to fix typo in 
blackberry"  #winedev/wine.atd is not submitted!

At 07:16 AM 8/6/2009, Stephen Vance wrote:
>Large subsets for view resolution which 
>increases database lock time, memory requirements, and processor requirements.
>Large have tables increase your database sizes.
>Have tables have a high churn rate increasing 
>database fragmentation and slowing down performance.
>P4V and P4Win don't fstat all files on opening, 
>but they do fstat all files, changes, jobs, etc. 
>that are displayed and in scope. Larger clients 
>increase the scope, although not necessarily 
>more than "Entire Depot View" would.
>I strongly discourage catch-all clients. It 
>leaves opportunities for several mistakes and 
>best practice violations. It allows changelists 
>to span branches which violates the principle of 
>a changelist being a single logical change to a 
>codeline. It allows for sloppy or mistakenly 
>targeted integrations. Those are just two of the issues.
>Anders Kjærgaard Hansen wrote:
>>We are currently doing some housekeeping and 
>>cleanup in our Perforce user database, and old unused clients.
>>We came to discuss what impact large clients 
>>have on both the perforce server, but also our storage.
>>We have several users who was clients with views as //depot/... //client/...
>>What are the impacts of these "global" clients?
>>Do p4, p4v, p4win e.g. fstat all files in a 
>>client each time you open it in the application?
>>We are especially interested in hearing 
>>opinions on whether we should allow these clients or not.
>>We have tools supporting creation and use of correct product scoped clients.
>>I hope some of you have some valuable input
>>Sorry if I'm reposting this, my first mail didn't show up so I am retrying.
>>Best regards
>>perforce-user mailing list  -  perforce-user at perforce.com
>Stephen Vance
>perforce-user mailing list  -  perforce-user at perforce.com

Aura Ines Heinz
WCI LC Liaison
Lawrence Livermore National Laboratory
Phone:  (925) 423-7900
Fax: (925)423-5209
B132N R1250
perforce-user mailing list  -  perforce-user at perforce.com

More information about the perforce-user mailing list