Ian M. wrote:
> Thanks for the response Andy.
>
> As for the hangups:
>
> I just checked the performance (its a Win 2003 server box) and it
> pages/sec shoots to over a thousand when doing an update/commit, but
> it still maintains a great deal of free ram (of an available 4GB). I'm
> not really sure how to gauge the pages/sec in terms of what is good
> and bad (especially after reading this http://support.microsoft.com/kb/139609
> ), but it does seem to max out the performance graph.
>
> One thing I should mention is that the Subversion runs on our server
> here but the repository location is actually a network path to a
> folder on the NAS. Would this potentially cause an issue? Its
> difficult for me to test against this as we only have a single
> mirrored drive in the server for the OS to run on and not enough space
> to hotcopy a repository there for testing.
Can't you put the repository on the local harddrive of the server?
> As for the poor speeds:
>
> I get about 60Mbps transferring files directly to the NAS that stores
> the repositories (Gigabit network, but my laptop has 100Mb onboard),
> so I'm lead to believe that I should be getting better speeds than 3Mb
> when using local hostnames with checkouts. Of course this may relate
> back to the performance issue.
When accessing the repository, Subversion requires a *lot* of file
accesses (the repository is basically a database, consisting of hundreds
of files). That's why you will never get the full speed (except when
transferring a very big file): for every file that svn accesses, there's
a big overhead and delay because of the whole authentication/access
control over the network (your NAS has to check whether the server
process is even allowed to access those files).
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-10-10 21:55:55 CEST