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
lesmikes...@gmail.com
