views:

308

answers:

3
+2  Q: 

CVS Performance

Hi guys!

I have huge projects on a CVS repository, and I'm looking for ways to improve its performance. Would CVS compression help it? And what about encryption, does it degrade the speed?

Thanks!

+2  A: 

Performance issues are usually IO related. (Unless you can see your CPU maxing out at 100%). I'd recommend trying to put the repository on a faster drive array (RAID 10 and/or higher RPM drives) to see if that increases your performance. If you are accessing the repository over the internet, then its likely a bandwidth issue, although depending on how much data you are talking about, even a simple DSL connection should be able to handle it.

Nate Bross
Right, because everyone has a RAID 10 lying around just to try out ;-) I voted this up, but I think you should axe that part of your answer.
unforgiven3
Depends what type of server you have. If development is important, a good drive array is a must. 4x 1TB WD drives ~ $400. Hardly a bank breaker for a company.
Nate Bross
I wonder what consitutes 'huge' here... 350 bucks will get you an entry level Intel 80gb solid state disk, which will most likely cure all that ails you. I imagine seek time is very important to CVS repositories, and you can't get better than a good SSD for that.
Dave Markle
+3  A: 

cvs it self can't compress afaik, but if using ssh for transport ssh can do that (and do this by default I think). This will help if having slow connection. edit: actually cvs got the -z options (as ssh got the -C )

Encryption is not something one use to increase performance. Using ssh will do encryption aswell, but that's not for performance but security.

Wherever the repository sits, disk access for repository and temporary files will affect performance. That combined with memory. When checking out, cvs will build what to send to the client (as temporary files). This caused a lot of discaccess and in some cases memory usage (esp if dealing with big binary files).

Joakim Elofsson
+3  A: 

CVS will get slower over time through repeated use.

  • When you check-out the whole project, the server will need to create every directory (even if you've since removed it - purging directories after checkout hides this from you).
  • When you check-out, every file is opened and examined, this can be very slow if you have hundreds/thousands of files.
  • Things get even worse if you are not trying to get out the HEAD of the trunk as the contents need to be reconstructed prior to sending it to the client.

If after all of that, you want to improve performance of shifting the data between the server and the client, then you can (depending upon your content type) use the -z option for compressing. I find -z6 to be best, but depending upon the nature of your files, you may want more/less compressing.

-z GZIPLEVEL

Sets the compression level on communications with the server. The argument GZIPLEVEL must be a number from 1 to 9. Level 1 is minimal compression (very fast, but doesn't compress much); Level 9 is highest compression (uses a lot of CPU time, but sure does squeeze the data). Level 9 is only useful on very slow network connections. Most people find levels between 3 and 5 to be most beneficial.

A space between -z and its argument is optional.

Ray Hayes