Re: Public Access to Perforce?

From: Gordon Tetlow <gordon_at_freebsd.org>
Date: Wed, 25 Aug 2004 17:55:28 -0700
I'm writing this with my Perforce administrator hat on.

On Mon, Aug 16, 2004 at 01:04:03AM -0400, Chris BeHanna wrote:
> 
>     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

Received on Wed Aug 25 2004 - 22:57:24 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:08 UTC