ntation yourself. There should be room for improvement,
especially if the server was made smarter.
A situation with high latency tunnelling is naturally very hard to improve
with a client<->server roundtrip-heavy design.
For best performance you really want your SVN server on the LAN.
Guten Tag Daniel Shahaf,
am Montag, 24. Februar 2020 um 18:27 schrieben Sie:
> If the remote repository uses https://, you could set up mod_dav_svn on
> localhost in a proxy configuration. For svn:// the equivalent would be
> to set up an svnsync mirror and do «svn relocate»'s to and from it by
>
Thorsten Schöning wrote on Mon, 24 Feb 2020 18:19 +0100:
> During merges this regularly leads to conflicts which TortoiseSVN
> tries to resolve by searching the repo for new merge targets and that
> search is incredibly slow if executed remotely.
>
> I tried to do the same merge using 2 URL-merges
Hi all,
I have a repo with 178'000 revisions and am accessing that using
OpenVPN and my home-DSL with 28/2 MBit/s. Most of the revisions
originate in branches I'm not interested of and are created
automatically by some software.
I have two unrelated feature branches based on trunk which I need to
es).
>
> What makes you think the slowness is svnserve's fault? Is the commit
> faster over file:// than over svn://localhost?
There is more that can be tried to reduce I/O and to check
whether there it results in improved performance:
* use 'svn import' instead of add/comm
Jakub Petr wrote on Thu, Dec 22, 2016 at 10:28:24 +0100:
> Why the "transmitting phase" should take so long?
Usually it's because of virus scanners intercepting the disk operations
(opening/writing files).
What makes you think the slowness is svnserve's fault? Is the commit
faster over file:// t
Hi,
I am suprised by poor performance of svnserve and not sure how can I improve
it.
Test case
I am on a Windows 10 laptop with i7 and SSD. (tested on Windows server too
with similar performance)
I am running both server and client on the laptop - so it doesn't go through
the ne
noticed a significant
> speed bump. However, I've got a repository where even this big jump didn't
> fix the performance problems. Current behavior is to appear to pause
> significantly, then report two versions verified. The pause lasts on the
> order of thirty seconds.
>
On Tue, Nov 01, 2016 at 12:14:32AM -0700, Eric Johnson wrote:
> Since I have on the order of 230,000 additional commits to check, I'm
> looking at 39 days before my repository finishes verifying. That's not
> really acceptable.
>
> Any suggestions? Am I doing something wrong?
You could try to
run
big jump didn't fix the performance problems. Current behavior is to
appear to pause significantly, then report two versions verified. The
pause lasts on the order of thirty seconds.
Since I have on the order of 230,000 additional commits to check, I'm
looking at 39 days before my re
On Fri, Jun 17, 2016 at 3:08 AM, Brandon Eusebio wrote:
> Hello Johan,
>
> Thank you so much for your response! It was incredibly helpful and clear.
>
> You were correct in the fact that my "tar" command was not preserving the
> correct modified timestamps. It turns out that the default tar forma
s the "stat" command.
You have been an awesome help. Thanks again!
All the best,
Brandon
-Original Message-
From: Johan Corveleyn [mailto:jcor...@gmail.com]
Sent: Thursday, June 16, 2016 12:35 AM
To: Brandon Eusebio
Cc: users@subversion.apache.org
Subject: Re: Performance Decreas
Hi,
Brandon Eusebio wrote:
> I am trying to move/copy a Subversion (version 1.8.10) working copy
> from one linux machine to another.
[...]
> however the performance of svn operations becomes drastically slower.
Are the machines software identical w.r.t. svn and it's dependencies?
>
> `tar -xpz -f checkout_directory.tar.gz`
>
>
>
> This achieves the goal of moving the working copy to the destination
> machine; however the performance of svn operations becomes drastically
> slower. For example, a `svn status` on the original machine takes < 1
> minute
copy using tar.
On source machine:
`tar -cpz -f checkout_directory.tar.gz checkout_directory`
On destination machine (after copy of the tarball):
`tar -xpz -f checkout_directory.tar.gz`
This achieves the goal of moving the working copy to the destination machine;
however the performance of svn
ttp://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.authz.pathauthzoff>),
or querying mod_authz_svn directly (short_circuit). The default value of this
directive is On.
On 10/9/15 11:05 AM, Philip Martin wrote:
"Weatherby,Gerard" <mailto:gweathe...@uchc.edu> write
"Weatherby,Gerard" writes:
> It "works" but the performance makes it nearly unusable. Monitoring
> the server using the top linux utility indicates many, many
> invocations of "pwauth" for a single client request. The next thing I
> was going to try w
av using apache2 and pwauth for validation
> -- we have other resources and prefer using the same authentication for all
> for simplicity.
>
> It "works" but the performance makes it nearly unusable. Monitoring the
> server using the top linux utility indicates many,
2 and pwauth for validation --
we have other resources and prefer using the same authentication for all for
simplicity.
It "works" but the performance makes it nearly unusable. Monitoring the server
using the top linux utility indicates many, many invocations of "pwauth" for a
s
>
>>> Is it a known issue? Has someone encouter thsi behavior?
>>>
>>
>> There is a known issues that might apply: The number of
>> entries (immediate children) in a directory should not exceed
>> a few 1000, see the warning box in 1.7 release note
ceed
> a few 1000, see the warning box in 1.7 release notes:
>
>
> http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning
>
> If all 30k files are from a single "flat" directory or is there one
> large directory somewhere in this tree, you
children) in a directory should not exceed
a few 1000, see the warning box in 1.7 release notes:
http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning
If all 30k files are from a single "flat" directory or is there one
large directory somewhere in this tre
Hi Nouha,
Based on the relative size of the repositories, one might expect that the
larger repository would take about twice as long to export. So clearly
something is weird here.
You'll still need to provide more details:
- Are the types of files in the two repositories different?
- Are y
Hello Eric,
Many thanks for your answer.
What's the client on which you're running the svn export command?
> I tested with 2 svn clients: 1.6.11 and 1.8.8 from an RH 5 server and got
the same response time for both export
Are you doing the export across the network, or on the same machine hostin
Looks like nobody has responded yet. I've certainly not encountered that
behavior.
I think you'll need to provide more information. The problem could stem
from so many places. Could be, for example, that you've got a virus
scanner, and when you export the 30K files, you're exporting files that
dra
Hello all,
we are deploying svn 1.8.11 on our server Rhel 6.6.
We are facing some issue within svn export.
it seems that it has some perf limitation when dealing with a huge number
of files.
we have this delay when doing an svn export url and the target has:
less than 20k files export = ~ 1 min
On Fri, May 16, 2014 at 2:05 PM, Ben Reser wrote:
> On 5/15/14, 1:15 AM, Terry Dooher wrote:
> > That's so much clearer now and sounds like something I can definitely
> use.
> > As I understand it, the downside is that the server will reveal path
> components
> > and filenames within restricted a
On 5/15/14, 1:15 AM, Terry Dooher wrote:
> That's so much clearer now and sounds like something I can definitely use.
> As I understand it, the downside is that the server will reveal path
> components
> and filenames within restricted areas during log operations?
Don't think you quite understand
ally must have this enabled if you have
> revprop packing turned on. I can't think of a reason you don't want this
> turn off other than desiring to reduce resource usage at the cost of slower
> performance.
>
> The documentation in question is the release notes:
> http://sub
Hi all,
I've just finished a dump/load cycle on about 500GB worth of repositories to
bring in the more efficient changes for FSFS in 1.8 (We're on 1.8.8 now). I'm
looking at utilising some performance tweaks to make the most of the hardware
the server is running on. Could so
ation module that also looks
at paths this added overhead does nothing for you. LDAP and other external
authentication makes the performance of this worse, however it's still a
measurable performance delay without such systems.
off: The secondary path setting does not run. It presumes if you h
On 5/14/14, 12:06 PM, Ben Reser wrote:
> Actually I think it's more that you really must have this enabled if you have
> revprop packing turned on. I can't think of a reason you don't want this turn
> off other than desiring to reduce resource usage at the cost of slow
> move tracking), at the expense of poorer performance on a remote
>> filesystem that is, when you get right down to it, a 30-year-old
>> dinosaur that was never designed for the kind of use that people these
>> days seem to assume it can support.
>
> The new working copy
Branko Čibej writes:
> We made a conscious decision
> to design a working copy format that's faster than the old format could
> ever have been and can better support new features (such as client-side
> move tracking), at the expense of poorer performance on a remote
> file
mpatible using
junctions. Depending on your checkout directory, resolving a junction
may impact performance on each and every activity of your file system
regarding the checkout, something which surely won't be the case under
ext4 again because most of the users simply store in /home/xyz without
an
On 4/28/14, 8:41 AM, Les Mikesell wrote:
> There's no concurrent access happening - just home directories where a
> user will be working on one machine or another - which is mostly
> transparent to normal applications.. Should there be a difference if
> they work on the server hosting the exported
es with working copy metadata.
> The latter is never mostly read-only; even a simple "svn update" that
> doesn't change any working file can modify lots of metadata, and this is
> where locking is involved.
>
> Will the subversion performance issue affect local storage t
gt;>
>> You're confusing the contents of versioned files with working copy metadata.
>> The latter is never mostly read-only; even a simple "svn update" that
>> doesn't change any working file can modify lots of metadata, and this is
>> where locking is in
files with working copy metadata.
> The latter is never mostly read-only; even a simple "svn update" that
> doesn't change any working file can modify lots of metadata, and this is
> where locking is involved.
Will the subversion performance issue affect local storage th
On Sat, Apr 26, 2014 at 5:02 PM, Roman Naumenko wrote:
> But git clients are doing pretty good on nfs, no?
git performance, and working copy consistency, is a wholde different
kettle of fish than subversion.
#exclusivelocking
Mark, thank for the link. There is indeed a nice performance boost to the
client with exclusive access.
Anyone who insists on using Subversion on NFS, whether as client or
server, should be aware of two things:
* File locking is, at best, flaky on NFS (even NFSv4+); and it&#
On 26.04.2014 00:51, Les Mikesell wrote:
> On Fri, Apr 25, 2014 at 4:34 PM, Branko Čibej wrote:
>
>> To stray off topic for a minute here, though: the idea that working copies
>> are "cheap throwaway stuff" is less than universally true. I've seen complex
>> sparse working copies with many gigabyt
g/docs/release-notes/1.8.html#exclusivelocking
The exclusive locking limits you to one client, but since we're not making and
releasing a lot of locks you gain performance at the cost of losing concurrency
from multiple svn clients using the same working copy. In a build server you
shouldn't need this
On Fri, Apr 25, 2014 at 4:34 PM, Branko Čibej wrote:
>
> Working copies are supposed to be throwaway things that can always be
> fixed to the last commit by the server. Why wouldn't you want to use
> something fast, cheap, and highly buffered for that, even if it is
> half baked?
>
>
> Conversely,
corruption bug; and, of course, they were an order of magnitude slower
on local storage than the latest releases. We made a conscious decision
to design a working copy format that's faster than the old format could
ever have been and can better support new features (such as client-side
move
On Fri, Apr 25, 2014 at 3:26 PM, Branko Čibej wrote:
>>
> If you absolutely must put your working copies or repositories on non-local
> storage, you should use a SAN with a real, multi-homed distributed
> filesystem. Anything else is half-baked, at least as far as data integrity
> is concerned.
W
r the link. There is indeed a nice performance boost to the
> client with exclusive access.
Anyone who insists on using Subversion on NFS, whether as client or
server, should be aware of two things:
* File locking is, at best, flaky on NFS (even NFSv4+); and it's
always slow. This
> > >
>
> > > Let's do be careful to draw distinctions between local file
> > > systems,
>
> > > like NTFS and ext4, and network file systems like CIFS and NFS.
> > > I'm
>
> > > afraid it's common to handwave those a
faster.
> > >> Any ideas why?
> > >
> > >
> > > There are probably some good discussions about this in the archives
> > > during
> > > the run-up to 1.7 but my memories are fading. I do not think
> > > anyone ever
> > > said th
the run-up to 1.7 but my memories are fading. I do not think
> > anyone ever
> > said that the difference would be "solved" but more that the
> > architectural
> > changes in 1.7 were going to close the performance gap on Windows
> > when
> > compared
On 16 April 2014 21:13, Florian Ludwig wrote:
> Hi,
>
> this topic was raised several times in the past - the answers range from
> "will be better/solved in the next version 1.7" or "it is due to ntfs vs
> ext3/4" or it's the AV, network setup or the Windows file indexing service.
> After disablin
Grierson, David said the following, on 23-04-14, 5:47 AM:
Latency Numbers Every Programmer Should Know:
https://gist.github.com/jboner/2841832
Always useful to have in mind when considering your benchmarking environment.
Looks like svn checkouts repos on Windows strictly through Netherlands.
Johan Corveleyn said the following, on 22-04-14, 9:30 AM:
On Tue, Apr 22, 2014 at 2:55 PM, Florian Ludwig
wrote:
From your numbers I deduce that the performance degradation can be
attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
* NTFS vs. ext4: roughly a factor 3 slower
Florian Ludwig said the following, on 16-04-14, 1:13 PM:
Hi,
this topic was raised several times in the past - the answers range
from "will be better/solved in the next version 1.7" or "it is due to
ntfs vs ext3/4" or it's the AV, network setup or the Windows file
indexing service. After dis
g
> Subject: Re: Subversion Windows Performance compared to Linux
>
> On Tue, Apr 22, 2014 at 9:53 AM, Mark Phippard wrote:
> > On Wed, Apr 16, 2014 at 1:13 PM, Florian Ludwig
>
> > wrote:
> >
> >>
> >> this topic was raised several times in the pas
y?
>
>
> There are probably some good discussions about this in the archives during
> the run-up to 1.7 but my memories are fading. I do not think anyone ever
> said that the difference would be "solved" but more that the architectural
> changes in 1.7 were going to c
then there was
>> really little done in 1.7 or 1.8 to speed it up. Most of the big
>> performance wins in 1.7 came in other areas. For example, update got a lot
>> faster on Windows on working copies with lots of folders because the time
>> to "lock" the working
t of the big
> performance wins in 1.7 came in other areas. For example, update got a lot
> faster on Windows on working copies with lots of folders because the time
> to "lock" the working copy got a lot slower.
>
commit / update seems slower as well but I don't have any num
.7 but my memories are fading. I do not think anyone ever
said that the difference would be "solved" but more that the architectural
changes in 1.7 were going to close the performance gap on Windows when
compared to SVN 1.5/1.6 on Linux. There were a couple of big performance
fixes bac
bject: Re: Subversion Windows Performance compared to Linux
From your numbers I deduce that the performance degradation can be
attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
* NTFS vs. ext4: roughly a factor 3 slower.
* Windows 7 vs. Linux: roughly a factor 2.5 slow
On Tue, Apr 22, 2014 at 2:55 PM, Florian Ludwig
wrote:
>
>>
>> From your numbers I deduce that the performance degradation can be
>> attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
>> * NTFS vs. ext4: roughly a factor 3 slower.
>> * Windows
> From your numbers I deduce that the performance degradation can be
> attributed partly to NTFS vs. ext4, and partly to Windows7 vs. Linux:
> * NTFS vs. ext4: roughly a factor 3 slower.
> * Windows 7 vs. Linux: roughly a factor 2.5 slower.
>
You assume that the file operation
*: 3m 29s
> * Windows 7 on NTFS*: 9m 19s
>
> [*] Same partition
Interesting. I think you'll find a much larger difference with a 1.6
client and older (the old working copy generation) ... 1.7+ has closed
the gap a bit, but as you show there is still a very significant
difference.
Hi,
On Wed, Apr 16, 2014 at 7:33 PM, Andreas Stieger wrote:
> Can you re-run with --quiet?
>
Using --quiet did not make a difference. ( I was piping the output to
/dev/null or $null on windows so there was no output anyway. )
> Which version if SQLite is the GNU/Linux client running with?
>
Can you re-run with --quiet?
Which version if SQLite is the GNU/Linux client running with?
Regards,
Andreas
> On 16 Apr 2014, at 18:13, Florian Ludwig wrote:
>
> Hi,
>
> this topic was raised several times in the past - the answers range from
> "will be better/solved in the next version 1.7"
Hi,
this topic was raised several times in the past - the answers range from
"will be better/solved in the next version 1.7" or "it is due to ntfs vs
ext3/4" or it's the AV, network setup or the Windows file indexing
service. After disabling all those and running a test checkout on Linux
and Wind
It used to be much, much worse: see the old thread at
http://subversion.1072662.n5.nabble.com/Poor-performance-for-large-software-repositories-downloading-to-CIFS-shares-td155699.html.
A large improvement occurred for Subversion on CIFS in a following
Subversion release, I believe as a
commits are very slow compared to local disk access. Are there
> any samba server settings that would be likely to help with the speed?
The new-in-1.8 exclusive-locking option in ~/.subversion/config
can help performance on network filesystems (see below).
I would recommend against usi
I think this has been discussed here previously but I don't remember
any definitive conclusions so I'll ask again. We now have some
Windows users with samba-mounted disk space and large svn checkouts
and commits are very slow compared to local disk access. Are there
any samba server settings th
On our setup (10k RPM SAS RAID-10 across 6 spindles, AMD Opteron 4180
2.6GHz), we're finding that "svnadmin verify" is CPU-bound and only uses
a single CPU core.
Is it possible that "svnadmin verify" could be multi-process in the
future to spread the work over more cores? Or is that technical
On Thu, Aug 1, 2013 at 10:18 AM, Somashekarappa, Anup (CWM-NR)
wrote:
>
>
> Hello Bob,
>
> Thanks for your response.
>
> I tried in the same server where svn is hosted but there also it is taking
> too much of time I e it is taking 110 mins to checkout the 2200 Mbytes of
> data(in Windows it too
On Aug 1, 2013, at 09:26, Bob Archer wrote:
> The working copy is generally 2x the size of the files in it, since the .svn
> folder contains the pristine copies of your working copy. This is how svn can
> do diffs against changed items In your working copy without hitting the
> server, and als
things like how busy the disks are, how busy the CPU cores
are and the network throughput. This will give you an idea of how hard
the Linux server is working while sending out the data to the SVN client.
For the windows client, you will need to look at the Performance Monitor
(perfmon) and
To: Bob Archer
> Cc: Somashekarappa, Anup (CWM-NR); users@subversion.apache.org
> Subject: RE: SVN performance -URGENT
> Bob Archer wrote on 08/01/2013 09:02:32 AM:
> > > We are using subversion 1.7 which is hosted in linux and apache
> > > isbeing used along with this.
> >
On 1 Aug 2013 16:52, "Somashekarappa, Anup (CWM-NR)" <
anup.somashekara...@rbc.com> wrote:
>
> Bandwidth is 35.4 MBytes/sec from my system(London) to server(New york)
when i checked with iperf tool.
>
>
> We are using LDAP
>
> AuthzLDAPAuthoritative off
> AuthType Basic
> AuthBasicProvider ldap
>
01 August 2013 15:20
To: Bob Archer
Cc: Somashekarappa, Anup (CWM-NR); users@subversion.apache.org
Subject: RE: SVN performance -URGENT
Bob Archer wrote on 08/01/2013 09:02:32 AM:
> > We are using subversion 1.7 which is hosted in linux and apache
isbeing used
> > along with this.
Please stop top posting.
> I tried in the same server where svn is hosted but there also it is taking too
> much of time I e it is taking 110 mins to checkout the 2200 Mbytes of data(in
> Windows it took 143 mins).
>
> I have not tried the command line option.Could you please tell how to do it
>
Bob Archer wrote on 08/01/2013 09:02:32 AM:
> > We are using subversion 1.7 which is hosted in linux and apache
isbeing used
> > along with this.
> > The linux is very powerful but we are facing a major issue during the
SVN
> > operation from the windows system.
> > Windows system : Microsoft wi
> I tried in the same server where svn is hosted but there also it is
> taking too much of time I e it is taking 110 mins to checkout the
> 2200 Mbytes of data(in Windows it took 143 mins).
How many files are in the working copy? For example, millions of small
files can take a significant amoun
performance -URGENT
> Hello Team,
> We are using subversion 1.7 which is hosted in linux and apache is
> being used along with this.
> The linux is very powerful but we are facing a major issue during the
> SVN operation from the windows system.
> Windows system : Microsoft windo
> Hello Team,
> We are using subversion 1.7 which is hosted in linux and apache is being used
> along with this.
> The linux is very powerful but we are facing a major issue during the SVN
> operation from the windows system.
> Windows system : Microsoft windows XP
> 2.85 GB of Ram
> tortoisesvn 1.
> Hello Team,
>
> We are using subversion 1.7 which is hosted in linux and apache is
> being used along with this.
>
> The linux is very powerful but we are facing a major issue during the
> SVN operation from the windows system.
>
> Windows system : Microsoft windows XP
> 2.85 GB of Ram
> to
Guten Tag Somashekarappa, Anup (CWM-NR),
am Donnerstag, 1. August 2013 um 13:51 schrieben Sie:
> May i know where is the bottleneck?
Did you have a look at the CPU and I/O for storage and network on both
client and server? Even Windows provides enough tools built-in to see
if those resources are
Hello Team,
We are using subversion 1.7 which is hosted in linux and apache is being
used along with this.
The linux is very powerful but we are facing a major issue during the
SVN operation from the windows system.
Windows system : Microsoft windows XP
2.85 GB of Ram
tortoisesvn 1.7
Windows
t;> Increasing the cache size can reduce disk IO and improve performance:
>>
>> http://subversion.apache.org/docs/release-notes/1.7.html#server-performance-tuning
>
> That's one of the options I was looking at. When I checked mem
> allocation on the server, it appeared t
On 2013/07/10 9:41 AM, Philip Martin wrote:
> "Naumenko, Roman" writes:
>> That box has more than enough CPUs (forty), cores are barely utilized.
> Subversion's default cache configuration is very conservative.
> Increasing the cache size can reduce disk IO and
"Naumenko, Roman" writes:
> That box has more than enough CPUs (forty), cores are barely utilized.
Subversion's default cache configuration is very conservative.
Increasing the cache size can reduce disk IO and improve performance:
http://subversion.apache.org/docs/rele
On 2013/07/08 5:10 PM, Thomas Harold wrote:
> On 7/8/2013 2:18 PM, Naumenko, Roman wrote:
>>
>> That box has more than enough CPUs (forty), cores are barely utilized.
>> How is the access over ssh can be configured? I thought it's only
>> http(s) or svn proto.
> http://svnbook.red-bean.com/en/1.7/s
On Tue, Jul 9, 2013 at 1:31 AM, Andreas Krey wrote:
> On Mon, 08 Jul 2013 14:33:03 +, Andy Levy wrote:
>
>> I just checked out 2400 files, about 1.7GB, and it took just over 19 minutes.
>>
>> Client I/O speed is a big factor (7200RPM hard drive w/ NTFS in my case).
>
> 9550 Files, half a GB wc
Guten Tag Andreas Krey,
am Dienstag, 9. Juli 2013 um 11:02 schrieben Sie:
> the machine now under my desk
> writes a tree of 10 files and 7GB in about a minute (that is
> not an svn checkout).
And that's the hardware I wanted to read about, there surely is some
advanced RAID or SSD used and n
h it's server etc. I
> vote for the latter and claim that you didn't mention little details
> like an SSD for the working copy etc. Of course only because those
> would have only little impact on checkout performance... ;-)
No, that is an admittedly beefy machine with rotating rus
t mention little details
like an SSD for the working copy etc. Of course only because those
would have only little impact on checkout performance... ;-)
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-S
On Mon, 08 Jul 2013 18:06:45 +, Naumenko, Roman wrote:
...
> For example, on one of the other servers it takes 12-13 min to checkout
> repo with ~17000 files, total size 1.2G (with average speed 2MB/s).
>
> Is it considered good, bad or total disaster in term of svn performance?
On Mon, 08 Jul 2013 14:33:03 +, Andy Levy wrote:
> I just checked out 2400 files, about 1.7GB, and it took just over 19 minutes.
>
> Client I/O speed is a big factor (7200RPM hard drive w/ NTFS in my case).
9550 Files, half a GB wc size, 15 seconds.
You may want to use another file system?
On 7/8/2013 2:18 PM, Naumenko, Roman wrote:
That box has more than enough CPUs (forty), cores are barely utilized.
How is the access over ssh can be configured? I thought it's only
http(s) or svn proto.
http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.advanced.reposurls
http:/
2.2.3
>>>>>
>>>>> 128G mem
>>>>> 10G
>>>>> FSFS is local storage.
>>>> I don't see how this can be answered. There are too many variables to
>>>> consider. I/O performance, revision history of the items you
ow fast would you expect svn checkout to be from a server like one below?
>>>> Considering eveyrthing on the server functioning as expected.
>>>>
>>>> Apache 2.2.3
>>>>
>>>> 128G mem
>>>> 10G
>>>> FSFS is local
(with average speed 2MB/s).
>
> Is it considered good, bad or total disaster in term of svn performance?
I'd generally expect checkout performance to be limited by the
disk/filesystem speed of the client, especially since it has to also
write the hidden pristine copy. So a faster server may
>>> Considering eveyrthing on the server functioning as expected.
>>>
>>> Apache 2.2.3
>>>
>>> 128G mem
>>> 10G
>>> FSFS is local storage.
>> I don't see how this can be answered. There are too many variables to
>>
On Mon, Jul 8, 2013 at 2:18 PM, Naumenko, Roman
wrote:
> On 2013/07/08 2:06 PM, Thomas Harold wrote:
>> On 7/8/2013 11:32 AM, Naumenko, Roman wrote:
>>> Hello,
>>>
>>> How fast would you expect svn checkout to be from a server like one
>>> below? Considering eveyrthing on the server functioning as
1 - 100 of 206 matches
Mail list logo
