On 5/5/2010 8:46 AM, Brendan Farr-Gaynor wrote:
> Hi Andy,
>
> Thanks for your response! Running local copies of the environment doesn't seem practical in this case, my guys are working on 10+ projects at a time all of which can be in different states and which need many different modules in place via apache and php which would take forever to setup and even support across multiple workstations. Not having to worry about client machine consistency keeps things sane (in my opinion). When the commits are fast, the central model works well, I'm just trying to figure out a way to keep them fast.
>
> The network *shouldn't* be an issue, traffic is fairly light and is gigabit to all of the machines. (I'm not sure how to test this beyond some pings). We do have a very small commit hook which updates an Apache web root with the changed file so that developers can see their changes in-browser. (how could I check the speed of this?). We don't commit *large* binaries, in our web projects however there are lots of common .jpg's and .png's for our interfaces each weighing in at no more than 100k. We're not updating these often though, could these be the big problem?
>
> Yes, we are serving the repo via Apache. I will try a restart to see if things feel faster. (Should I be watching memory usage on Apache in this instance?)
Why don't you run viewvc or websvn for browser access so you don't have
to wait for anything extra during commits? Just in general, disk seeks
are the slowest operation on a computer and anything you can do to avoid
them will speed things up even if you don't know the exact details about
them. If you only have one drive, it would help to put the repository
on a different one so the apache logs don't compete for head position.
Most OS's will use added RAM for filesystem cache and speed things up
indirectly by avoiding the need to seek for repeated reads. There are
also some subtle things that can slow performance like having apache set
to log client hostnames and a DNS server that responds slowly on reverse
lookups.
--
Les Mikesell
lesmikesell_at_gmail.com
Received on 2010-05-05 17:13:31 CEST