Re: CVS Server Slow

[panarat]

Todd Denniston wrote:
> 
> luke.m wrote, On 12/01/2008 04:29 AM:
>> Hi all,
>> 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
>> 1.8.31.
>> 
>> Any ideas?
>> 
>> Tnx in advance and sorry for my english!
> 
> Assumptions:
> 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 
> accounts.
> 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
> CVSNT newsgroup:
> http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt
> or
> news://news.cvsnt.org/support.cvsnt
> WinCVS newsgroup:
> http://groups.yahoo.com/subscribe/cvsgui
> TortoiseCVS newsgroup:
> http://sourceforge.net/mail/?group_id=48103
> 
> 
> 
> Good luck hunting.
> -- 
> Todd Denniston
> Crane Division, Naval Surface Warfare Center (NSWC Crane)
> Harnessing the Power of Technology for the Warfighter
> 
> 
> 
> 
Hi there, I have a problem of CVS update slow

It happens slow for the second update, but the first update is quick. I am
afraid it is about latency something.
Can it be set from ssh pramgram/ putty?

My CVS version is
Client: Concurrent Versions System (CVS) 1.12.13 (client/server)
Server: Concurrent Versions System (CVS) 1.12.13 (client/server)

I also have tried "CVS status tools.pm"
===================================================================
File: tools.pm Status: Up-to-date

Working revision: x.x.x.x
Repository revision: x.x.x.x /usr/local/CVSROOT/***/***/tools.pm,v
Commit Identifier: xxxxxxxx
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
the result is like above in timely manner, but once I run "CVS status
tools.pm" again , it uses a lot of time to get the prompt password.

Anyone has any ideas about this?
-- 
View this message in context: 
http://old.nabble.com/CVS-Server-Slow-tp20768685p26897624.html
Sent from the Gnu - Cvs - Info mailing list archive at Nabble.com.