Re: cvs pserver performance

[Donald Sharp]

On Wed, Jan 10, 2001 at 12:56:52PM -0800, Russ Tremain wrote:
> Hi -
> 
> I've reviewed much of the discussion on this list on
> CVS server performance, in hopes of finding something related
> to the problems we are experiencing our CVS server.  So far, I
> haven't found anything similar to what we are experiencing.
> Apologies if this is a re-hash.
> 
> We are running cvs 1.10.8 as a pserver on a rather beefy
> solaris system.  Our repository is fairly large and contains
> about 45,000 files.  This machine is idle most of the time,
> and its only job is to run the CVS server.
> 
> Performance is adequate when one client does a full CVS update.
> This update takes 15-20 minutes.
> 
> When a second client updates, both updates slow substantially,
> taking about 35-40 minutes.
> 
> When three clients are updating simultaneously, the update
> time starts to climb to about 1.5 hours per client.
> 
> Surprisingly, the packet traffic goes *down* as more clients
> attach.
> 
> When a truss a client that is particularly slow, I find
> that it is loosing, (and therefore requesting a retransmit of,)
> about every third packet.

This is a network problem, not a cvs problem.

> 
> When I snoop on the ethernet interface, I find that all clients
> are sending to the server port 2401.

Yep that's right.

> 
> I was surprised by this, since most servers only listen on
> a well-known socket for connections, negotiate a private socket
> to handle a particular client, and then use this new socket for
> further communications.

That's not necessarily true, there is not necessarily a need 
to do it this way.  Sockets form tuples( client ip, client port,
server ip/port )of information that provide information to the kernel 
where to route the incoming and outgoing packets.  inetd in this
case is managing the incoming data and sending the information to
the correct cvs process.

> 
> My understanding is that if a bunch of processes are reading
> the same socket, then the packet is consumed by the first
> reader.

cvs isn't reading the incoming socket.  inetd is reading the
incoming information and passing it on to the stdin of the cvs process.
So in this case only one process is actually reading all incoming
sockets.


> 
> Therefore, the retransmits would make sense as a source of the
> poor performance we are experiencing when we have multiple
> updates running.

retransmits are part of the poor performance, but cvs has no ability 
to affect this.  This is strictly a networking issue.

remember directory contention via lock files could also be significantly
slowing down updates as well.  Especially over such a large repository.

> 
> Tell me it isn't true...
> 
> If it is true, then is there an easy work-around?  I would like to
> retain the pserver strategy...but I suppose we could revert to NFS
> for subsets of clients.

Fix your network.

donald
> 
> Thanks for any help or suggestions...
> 
> Regards,
> -Russ
> 
> Russ Tremain
> address@hidden
> 
> Senior Architect, Infrastructure Engineering
> Forte Tools Division
> Sun Microsystems, Inc.
> 
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs