7 messages in com.perforce.perforce-user[p4] Performance question
FromSent OnAttachments
Martin Ellison23 Aug 2000 17:35 
Peter Theunis23 Aug 2000 18:22 
Chuck Karish24 Aug 2000 07:07 
axel...@coremedia-ag.com25 Aug 2000 01:37 
Andrew Dalgleish25 Aug 2000 03:01 
Lawrence You25 Aug 2000 13:28 
Kearney, Greg25 Aug 2000 13:45 
Subject:[p4] Performance question
From:Andrew Dalgleish (andr@axonet.com.au)
Date:08/25/2000 03:01:13 AM
List:com.perforce.perforce-user

From: Martin Ellison <martin.ellison at bullant.com> To: "'perforce-user at perforce.com'" <perforce-user at perforce.com> Date: Thu, 24 Aug 2000 10:36:20 +1000 charset="iso-8859-1" Subject: [p4] Performance question

We raised this with Perforce support and they suggested checking the [no]compress option on the client. As it happened, the user had nocompress set and when she changed that setting to compress it did improve performance. However, we are wondering if there are any tuneable parameters (documented or undocumented) that may help (whether Perforce, TCP/IP or whatever).

[Andrew Dalgleish]

We use Perforce between Melbourne and various parts of USA + Canada and find the performance acceptible. (Untill someone checks in a 100MB binary without telling anyone. :-)

A few suggestions: * If you are using SSH make sure that you dont have both SSH and perforce trying to do compression. * Check the tcp "max path MTU discovery" settings for your client, server and firewalls. (Search the MS KB for details. Sometimes SSH tunnelling via a non-windows box is *faster* than a direct connection because of this.) * Try doing a "p4 sync" from a different client OS. * Does the server also have a remote depot pointing somewhere else? This can cause a big performance hit.

Has anyone tried installing a perforce server with a remote depot on each remote client? This would only provide read-only access, but I am wondering if it would be any faster. Which server stores the client state, the local server or the remote depot?

Regards, Andrew Dalgleish