[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Server Slow
Re: CVS Server Slow
Mon, 01 Dec 2008 14:50:34 -0500
Thunderbird 22.214.171.124 (X11/20081105)
luke.m wrote, On 12/01/2008 04:29 AM:
i've just done setup of my new CVS server on RHEL 5.
All works fine but i've a problem with some users: they can
co/update/commit... from/to repo but the server is veeeeeeery slow, always
slow. For other users the server is fast, always fast. I.E. to co a module
large about 380MB the "fast client" done that operation in about 220 sec and
"slow client" in 460-1100 sec.
All client are running MS Windows XP (same sp and patch) and TortoiseCVS
Tnx in advance and sorry for my english!
a) all clients are using the same $CVSROOT setting.
b) all clients are using the same connection method (i.e., if using :ext: all
are using ssh.
c) the .ssh/config for the fast ones does not have compression turned on.
d) the .cvsrc for the fast ones does not have compression turned on.
e) time trials are being done with only one client hitting the server (i.e.,
you have yelled 'everyone out of the CVS server for the next hour' while doing
the tests, and folks complied).
f) the server is not periodically being used for something else, like building
the Linux kernel.
g) the .bashrc|.profile|personal shell config files are the same in everyone's
h) all clients passes through the very _same_ _physical_ network
switches&routers&firewalls to get to the server.
i) you are running the time trial from the same client twice in a row to
average out caching issues on the server.
j) all clients is on a single speed LAN, i.e., 10Mb/s 100Mb/s 1000Mb/s (your
speeds above look like a fast 10Mb/s or slow 100Mb/s connection)
k) all clients have the same amount of ram, locked in swap space, speed of
processor, and speed of hard drive, space left on hard drive.
l) all clients were defragmented recently.
My best guesses are that at least one of the above are not true, and I would
look at them in the following order:
j, h, f, l, e, k, h*, g, d & c. We REALLY should be able to make a, b & i.
*if h is not true you need to be looking to see if the folks on the slow
clients have a network component that is breaking/broken, or if someone is
streaming video or audio into that part of the network.
As it is always fast for some folks, I would pretty much assume it is either a
network or client machine/config issue, so You might also want to ask for
other windows client issues on one or more of the following lists:
Following list borrowed from Arthur Barrett
Good luck hunting.
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter