You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by "Naumenko, Roman" <ro...@rbccm.com> on 2013/07/08 17:32:42 UTC
Expected performance
Hello,
How 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
<svn version=1.7.8 (r1419691)>
128G mem
10G
FSFS is local storage.
Thanks,
--Roman Naumenko
_______________________________________________________________________
This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.
Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Expected performance
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jul 8, 2013 at 2:18 PM, Naumenko, Roman
<ro...@rbccm.com> 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 expected.
>>>
>> Our bottleneck is usually the CPU, but we're doing svn+ssh access. So
>> I lean towards a few less but more powerful cores.
>>
>> The only time we thrash the disks is when doing the nightly hotcopy of
>> our repositories (total of about 110GB).
>
> 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.
Unless you've got a very, very heavily utilized server, more than 4
cores is probably overkill. Disk I/O is more important than CPU cores
for most users.
Re: Expected performance (svn+ssh)
Posted by "Naumenko, Roman" <ro...@rbccm.com>.
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/svn.basic.in-action.html#svn.advanced.reposurls
>
>
> http://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
>
>
> svn+ssh access has some upsides and downsides. For us, it was simpler
> to get up and running with it back in 2007 when we were still getting
> our feet wet with SVN 1.4. We weren't ready to muck around with
> Apache httpd and SSL certificates to do https access to the repository.
>
> We grant access at the repository level via Linux file system
> permissions. This means that every user needs to have their own
> system account and belong to Linux group that owns the repository.
>
> chown -R svn-group1 /var/svn/svn-repository1
> chmod -R 770 /var/svn/svn-repository1
> chmod -R g+s /var/svn/svn-repository1
>
> Where the 770 is some combination of, 770, 775, 755, 750, 700.
>
> 770 = owner read/write, group read/write, other none
> 750 = owner read/write, group read-only, other none
>
> To keep things sane, we do not set permission by hand, but edit a
> script that can be re-run to fix permissions on the repositories. Most
> of our repositories follow a set naming pattern, which makes it easier.
>
> The other advantage of svn+ssh is that it works well when using FSVS,
> because you can edit ~/.ssh/config so that FSVS can login to the SVN
> server automatically and push/pull configuration file changes.
Thank you, its interesting.
--Roman
_______________________________________________________________________
This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.
Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Expected performance (svn+ssh)
Posted by Thomas Harold <th...@nybeta.com>.
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://svnbook.red-bean.com/en/1.7/svn.serverconfig.svnserve.html#svn.serverconfig.svnserve.sshtricks
svn+ssh access has some upsides and downsides. For us, it was simpler
to get up and running with it back in 2007 when we were still getting
our feet wet with SVN 1.4. We weren't ready to muck around with Apache
httpd and SSL certificates to do https access to the repository.
We grant access at the repository level via Linux file system
permissions. This means that every user needs to have their own system
account and belong to Linux group that owns the repository.
chown -R svn-group1 /var/svn/svn-repository1
chmod -R 770 /var/svn/svn-repository1
chmod -R g+s /var/svn/svn-repository1
Where the 770 is some combination of, 770, 775, 755, 750, 700.
770 = owner read/write, group read/write, other none
750 = owner read/write, group read-only, other none
To keep things sane, we do not set permission by hand, but edit a script
that can be re-run to fix permissions on the repositories. Most of our
repositories follow a set naming pattern, which makes it easier.
The other advantage of svn+ssh is that it works well when using FSVS,
because you can edit ~/.ssh/config so that FSVS can login to the SVN
server automatically and push/pull configuration file changes.
Re: Expected performance
Posted by Philip Martin <ph...@wandisco.com>.
"Naumenko, Roman" <ro...@rbccm.com> writes:
> On 2013/07/10 9:41 AM, Philip Martin wrote:
>> "Naumenko, Roman" <ro...@rbccm.com> 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/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 that 85% was used as cache, I
> thought apache process would take advantage of OS caching by default.
It does, but that's caching the on-disk files. The Subversion in-memory
cache is for the data structures derived from the files.
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
Re: Expected performance
Posted by "Naumenko, Roman" <ro...@rbccm.com>.
On 2013/07/10 9:41 AM, Philip Martin wrote:
> "Naumenko, Roman" <ro...@rbccm.com> 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/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 that 85% was used as cache, I
thought apache process would take advantage of OS caching by default.
--Roman Naumenko
_______________________________________________________________________
This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.
Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Expected performance
Posted by Philip Martin <ph...@wandisco.com>.
"Naumenko, Roman" <ro...@rbccm.com> 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/release-notes/1.7.html#server-performance-tuning
--
Philip Martin | Subversion Committer
WANdisco | Non-Stop Data
www.wandisco.com
Re: Expected performance
Posted by "Naumenko, Roman" <ro...@rbccm.com>.
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 expected.
>>
> Our bottleneck is usually the CPU, but we're doing svn+ssh access. So
> I lean towards a few less but more powerful cores.
>
> The only time we thrash the disks is when doing the nightly hotcopy of
> our repositories (total of about 110GB).
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.
--Roman Naumenko
_______________________________________________________________________
This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.
Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Expected performance
Posted by Thomas Harold <th...@nybeta.com>.
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 expected.
>
Our bottleneck is usually the CPU, but we're doing svn+ssh access. So I
lean towards a few less but more powerful cores.
The only time we thrash the disks is when doing the nightly hotcopy of
our repositories (total of about 110GB).
Re: Expected performance
Posted by Les Mikesell <le...@gmail.com>.
On Mon, Jul 8, 2013 at 1:06 PM, Naumenko, Roman
<ro...@rbccm.com> wrote:
> >
> There are certainly a lot of variables. I'm just trying to find out some
> baseline.
>
> 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?
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 not matter
much except for concurrent activity.
--
Les Mikesell
lesmikesell@gmail.com
Re: Expected performance
Posted by Andreas Krey <a....@gmx.de>.
On Mon, 08 Jul 2013 18:06:45 +0000, 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?
To me this looks like 'bad'. I'd expect like a factor of ten more.
(C'mon, a local network can transfer that in 15 seconds, raw disk
performance isn't much worse either, and these aren't that many files.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Expected performance
Posted by Andy Levy <an...@gmail.com>.
On Tue, Jul 9, 2013 at 1:31 AM, Andreas Krey <a....@gmx.de> wrote:
> On Mon, 08 Jul 2013 14:33:03 +0000, 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?
Got any good recommendations for Windows 7 that will also be
compatible with my Windows Server 2008 R2 systems *and* my sysadmins
will accept?
Re: Expected performance
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Andreas Krey,
am Dienstag, 9. Juli 2013 um 11:02 schrieben Sie:
> the machine now under my desk
> writes a tree of 100000 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 no, this would not (yet) be common
hardware. My Crucial M4 SSD for example is pushing the bottleneck to
my 6 year old CPU, instead of NTFS itself.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Expected performance
Posted by Andreas Krey <a....@gmx.de>.
On Tue, 09 Jul 2013 09:52:22 +0000, Thorsten Schöning wrote:
...
> am Dienstag, 9. Juli 2013 um 07:31 schrieben Sie:
>
> > 9550 Files, half a GB wc size, 15 seconds.
>
> > You may want to use another file system?
>
> Or your hardware and connection to your repo with 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 rust
(although possibly raided), and GBit network access to the server.
Neither does the server have SSDs.
But the 1.5MByte/s that gets mentioned here seems quite unambitious;
with halfways decent hardware you should be able, in an svn checkout,
to saturate any network below 100MBit/s - the machine now under my desk
writes a tree of 100000 files and 7GB in about a minute (that is
not an svn checkout).
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Expected performance
Posted by Thorsten Schöning <ts...@am-soft.de>.
Guten Tag Andreas Krey,
am Dienstag, 9. Juli 2013 um 07:31 schrieben Sie:
> 9550 Files, half a GB wc size, 15 seconds.
> You may want to use another file system?
Or your hardware and connection to your repo with 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... ;-)
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail:Thorsten.Schoening@AM-SoFT.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...........05151- 9468- 55
Fax...............05151- 9468- 88
Mobil..............0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Expected performance
Posted by Andreas Krey <a....@gmx.de>.
On Mon, 08 Jul 2013 14:33:03 +0000, 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?
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: Expected performance
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jul 8, 2013 at 2:40 PM, Naumenko, Roman
<ro...@rbccm.com> wrote:
> On 2013/07/08 2:33 PM, Andy Levy wrote:
>> On Mon, Jul 8, 2013 at 2:06 PM, Naumenko, Roman
>> <ro...@rbccm.com> wrote:
>>> On 2013/07/08 12:51 PM, Andy Levy wrote:
>>>> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
>>>> <ro...@rbccm.com> wrote:
>>>>> Hello,
>>>>>
>>>>> How 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
>>>>> <svn version=1.7.8 (r1419691)>
>>>>> 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're
>>>> checking out, how much data you're checking out, server CPU and I/O
>>>> performance on the client end all come to mind.
>>>>
>>>> Do you have a specific performance concern?
>>> There are certainly a lot of variables. I'm just trying to find out some
>>> baseline.
>>>
>>> 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?
>> 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).
>
> Thanks Andy.
> Seems like 1.5-2MB/s for checkout speed is what expected and can be
> considered ok performance.
> Can anybody else confirm?
I don't think I implied that I thought it was "OK performance" -
that's just how fast my client/server combination runs. I'd be
overjoyed if I could make it run twice as fast, but since I have no
control over the server configuration or the configuration of the SAN
it's connected to (where my data is stored), I accept the performance
that I get and worry about bigger things that I *can* influence.
On a VM that runs on the same VMWare cluster as the SVN server, and
attached to the same SAN, the same checkout took just under 16
minutes.
I'm hoping that when we upgrade everything (clients and server) later
this year to 1.8.x, with a new server built out on a new VM host
cluster & SAN, it'll improve.
Re: Expected performance
Posted by "Naumenko, Roman" <ro...@rbccm.com>.
On 2013/07/08 2:33 PM, Andy Levy wrote:
> On Mon, Jul 8, 2013 at 2:06 PM, Naumenko, Roman
> <ro...@rbccm.com> wrote:
>> On 2013/07/08 12:51 PM, Andy Levy wrote:
>>> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
>>> <ro...@rbccm.com> wrote:
>>>> Hello,
>>>>
>>>> How 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
>>>> <svn version=1.7.8 (r1419691)>
>>>> 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're
>>> checking out, how much data you're checking out, server CPU and I/O
>>> performance on the client end all come to mind.
>>>
>>> Do you have a specific performance concern?
>> There are certainly a lot of variables. I'm just trying to find out some
>> baseline.
>>
>> 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?
> 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).
Thanks Andy.
Seems like 1.5-2MB/s for checkout speed is what expected and can be
considered ok performance.
Can anybody else confirm?
--Roman Naumenko
_______________________________________________________________________
This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.
Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Expected performance
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jul 8, 2013 at 2:06 PM, Naumenko, Roman
<ro...@rbccm.com> wrote:
> On 2013/07/08 12:51 PM, Andy Levy wrote:
>> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
>> <ro...@rbccm.com> wrote:
>>> Hello,
>>>
>>> How 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
>>> <svn version=1.7.8 (r1419691)>
>>> 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're
>> checking out, how much data you're checking out, server CPU and I/O
>> performance on the client end all come to mind.
>>
>> Do you have a specific performance concern?
>
> There are certainly a lot of variables. I'm just trying to find out some
> baseline.
>
> 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?
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).
Re: Expected performance
Posted by "Naumenko, Roman" <ro...@rbccm.com>.
On 2013/07/08 12:51 PM, Andy Levy wrote:
> On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
> <ro...@rbccm.com> wrote:
>> Hello,
>>
>> How 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
>> <svn version=1.7.8 (r1419691)>
>> 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're
> checking out, how much data you're checking out, server CPU and I/O
> performance on the client end all come to mind.
>
> Do you have a specific performance concern?
There are certainly a lot of variables. I'm just trying to find out some
baseline.
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?
--Roman Naumenko
_______________________________________________________________________
This email is intended only for the use of the individual(s) to whom it is addressed and may be privileged and confidential.
Unauthorised use or disclosure is prohibited. If you receive This e-mail in error, please advise immediately and delete the original message.
This message may have been altered without your or our knowledge and the sender does not accept any liability for any errors or omissions in the message.
Ce courriel est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent.
Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite.
Si vous recevez ce courriel par erreur, veuillez m'en aviser immédiatement, par retour de courriel ou par un autre moyen.
Re: Expected performance
Posted by Andy Levy <an...@gmail.com>.
On Mon, Jul 8, 2013 at 11:32 AM, Naumenko, Roman
<ro...@rbccm.com> wrote:
> Hello,
>
> How 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
> <svn version=1.7.8 (r1419691)>
> 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're
checking out, how much data you're checking out, server CPU and I/O
performance on the client end all come to mind.
Do you have a specific performance concern?