info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cvs pserver performance


From: Larry Jones
Subject: Re: cvs pserver performance
Date: Wed, 10 Jan 2001 16:35:13 -0500 (EST)

Russ Tremain writes:
> 
> 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.

There were a bunch of memory leaks in 1.10.8 that were fixed in 1.11
which could well cause the server process to grow very large and start
thrashing when checking out or updating that many files.  Upgrading may
help your performance and I'd recommend it in any case.

> When I snoop on the ethernet interface, I find that all clients
> are sending to the server port 2401.
> 
> 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.

You're confusing ports with sockets.  A socket is identified by the
local host address, the local port number, the remote host address, and
the remote port number.  Most servers work the same way CVS does: they
listen on a well-known *port* for connections; when they accept a
connection, they get a private *socket* that is used for further
communication.  That socket still has the well-known local port, but
each such socket has a different remote address/port.

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

That is correct, but each CVS server has a unique socket (they just all
have the same local port number).

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

If you're dropping network packets, you either have a network problem or
the server is badly overloaded.  You need to identify where the packets
are getting dropped and, if it's the server, you need to do some
performance analysis on it to discover the problem.  The O'Reilly book
on System Performance Tuning is a good place to start (www.ora.com).

-Larry Jones

Buddy, if you think I'm even going to BE here, you're crazy! -- Calvin



reply via email to

[Prev in Thread] Current Thread [Next in Thread]