From owner-freebsd-current@FreeBSD.ORG Thu Aug 26 00:57:24 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3483716A4CE for ; Thu, 26 Aug 2004 00:57:24 +0000 (GMT) Received: from spiff.melthusia.org (spiff.melthusia.org [207.67.244.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A41043D2D for ; Thu, 26 Aug 2004 00:57:24 +0000 (GMT) (envelope-from gtetlow@spiff.melthusia.org) Received: from spiff.melthusia.org (gtetlow@localhost [127.0.0.1]) by spiff.melthusia.org (8.12.10/8.12.10) with ESMTP id i7Q0tS7W017914; Wed, 25 Aug 2004 17:55:28 -0700 (PDT) (envelope-from gtetlow@spiff.melthusia.org) Received: (from gtetlow@localhost) by spiff.melthusia.org (8.12.10/8.12.10/Submit) id i7Q0tSMO017913; Wed, 25 Aug 2004 17:55:28 -0700 (PDT) (envelope-from gtetlow) Date: Wed, 25 Aug 2004 17:55:28 -0700 From: Gordon Tetlow To: Chris BeHanna Message-ID: <20040826005527.GF54515@spiff.melthusia.org> References: <200408160104.03708.chris@behanna.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HnQK338I3UIa/qiP" Content-Disposition: inline In-Reply-To: <200408160104.03708.chris@behanna.org> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . User-Agent: Mutt/1.5.6i cc: current@freebsd.org Subject: Re: Public Access to Perforce? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2004 00:57:24 -0000 --HnQK338I3UIa/qiP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm writing this with my Perforce administrator hat on. On Mon, Aug 16, 2004 at 01:04:03AM -0400, Chris BeHanna wrote: >=20 > Is there a read-only account that the general public could use? No, and despite conspiracy theories, this is not because we don't like people looking at our dirty laundry. It's actually for technical reasons. > To alleviate load on perforce.freebsd.org, p4proxy could be set up > on the current cvsup mirrors. I'd likely set up my own proxy server > on my home box, just to improve local response time (and ease setting > up a local vendor branch for playing around). And p4proxy will not help alleviate the technical problems at all. Since you are going to ask I'll start to explain. For those of you that don't know, Perforce's model requires you to talk to the server ALOT. Every sync requires the server to track what versions of the files you have (regardless of whether you use the p4proxy or not, the server still needs to track the fact you have that file revision). This is in stark contrast to systems like CVS where the state of the client is only tracked on the client. Now imagine that we have 300 people interested in looking at our source tree. Here are some statistics: The metadata database for the perforce depot is currently about 6.4 GB. We have 118 users with with 183 clientspecs. Now, for anonymous readonly users, the database in question is the db.have which is currently just shy of 2 GB. so a bit of quick math tells me that is about 11 MB per clientspec or 16.5 MB per user. So if we were to give anonymous access and only 300 clients decided to check out an average source tree that our developers are working on, we are looking at over an additional 3.2 GB of database files that we have to deal with. That is a significant amount of growth. Now Perforce performance demands that as much of the metadata in memory as possible. We are already starting to see the pressure with the operations that our developers are doing on the depot. When we ask Perforce support about ways to improve it, they generally tell us to throw more memory at the problem but we are limited in how far we can go with that (the box already has 2GB of memory in it). So until Perforce learns how to let clients work in a completely disconnected mode (I've already submitted the feature request) it's just not going to happen. I suppose we could write a script that would go through and clean up old clients, but that doesn't help as the database won't shrink without some serious and hand wringing. Also, it would be very susceptable to attack. And knowing how we have some trolls that like to make our lives difficult, I'll pass on that in favor of sleeping easy. -gordon --HnQK338I3UIa/qiP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFBLTT/Ru2t9DV9ZfsRApHyAJ9qmh0+xRY+NEsI6LM30eYcQiufhQCfZHau Ru4JBJg9uskH6sY2Rt3nQBA= =jgCa -----END PGP SIGNATURE----- --HnQK338I3UIa/qiP--