CVS Performance

Question

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!

Unpriced

cvs compression? don't you mean ssh compression? – Wisner

Need a few more details: How are you accessing the repository? Same machine? Local network? Internet? To help you, we need to know where the likely bottlenecks are. – Associate

Local network. It appears to me that the bottleneck is the CVS itself. Because the server is running on a Xeon 2x3Ghz machine with SAS hard disks. – Unpriced

Can you watch the CPU use, Network IO, and Disk Queue Length on that server while doing a large update/commit? That should point you at the bottle neck. – Ballinger

Answer 1

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.

Wellspoken

Answer 2

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.

Ballinger

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. – Consecution

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. – Ballinger

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. – Eiland

Answer 3

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).

Wisner