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.
