On Mon, Jul 7, 2014 at 8:59 PM, Branko Čibej wrote:
> On 07.07.2014 20:44, Stefan Fuhrmann wrote:
>> ... it makes SVN parse the
>> whole 64k block that the OS provides anyway ...
>
> [off-topic]
>
> See, this is the kind of statement that makes me uneasy. You make an
> assertion about "the OS" (or
On Tue, Jul 15, 2014 at 11:16 PM, Neels Hofmeyr wrote:
> On Mon, Jul 07, 2014 at 05:23:14PM +0200, Branko Čibej wrote:
>> On 07.07.2014 17:07, C. Michael Pilato wrote:
>> > On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>> >> My technical opinion that FSFS7/log addressing is slower by design,
>> >> be
On Mon, Jul 07, 2014 at 05:23:14PM +0200, Branko Čibej wrote:
> On 07.07.2014 17:07, C. Michael Pilato wrote:
> > On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
> >> My technical opinion that FSFS7/log addressing is slower by design,
> >> because it's doing more (read index, then read data instead of j
On 7 July 2014 20:44, Julian Foad wrote:
> I should probably let Stefan answer this, but...
>
> C. Michael Pilato wrote:
>>> On 07.07.2014 17:07, C. Michael Pilato wrote:
On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
> My technical opinion that FSFS7/log addressing is slower by design,
>
On Mon, Jul 7, 2014 at 2:44 PM, Stefan Fuhrmann <
stefan.fuhrm...@wandisco.com> wrote:
> I just started the Windows tests in a "realistic" environment
> with a 4GB RAM server managing > 50GB of repository data.
> The goal is clearly that the default config is not slower than
> before and the compu
On 07.07.2014 20:44, Stefan Fuhrmann wrote:
> ... it makes SVN parse the
> whole 64k block that the OS provides anyway ...
[off-topic]
See, this is the kind of statement that makes me uneasy. You make an
assertion about "the OS" (or about "the CPU" or "the architecture") as
if it were generally t
On Mon, Jul 7, 2014 at 5:54 PM, C. Michael Pilato wrote:
> On 07/07/2014 11:23 AM, Branko Čibej wrote:
>> On 07.07.2014 17:07, C. Michael Pilato wrote:
>>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
My technical opinion that FSFS7/log addressing is slower by design,
because it's doing mo
On Mon, Jul 7, 2014 at 12:44 PM, Julian Foad
wrote:
>
> C-Mike, my understanding is that F7 comprehensively beats F6 speed, by
> large factors around x1.5 and more, in the kind of scenarios it's designed
> for. Caching is an assumed part of the design. I don't know how much it
> needs for what sc
arios are faster, some are slower, especially with the
currently-default small cache size. Ivan reported some such scenarios [2].
My general observation is that wider testing is needed to draw firm conclusions.
- Julian
[1] "Re: Current FSFS performance [RAW]"
<http://svn.haxx.se/dev/archive-2014-07/0004.shtml>
[2] "Subversion 1.9.0-dev FSFS performance tests"
<http://svn.haxx.se/dev/archive-2014-06/0065.shtml>
On 07/07/2014 11:23 AM, Branko Čibej wrote:
> On 07.07.2014 17:07, C. Michael Pilato wrote:
>> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>>> My technical opinion that FSFS7/log addressing is slower by design,
>>> because it's doing more (read index, then read data instead of just
>>> read data) an
On 07.07.2014 17:07, C. Michael Pilato wrote:
> On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
>> My technical opinion that FSFS7/log addressing is slower by design,
>> because it's doing more (read index, then read data instead of just
>> read data) and only caching makes them comparable on performanc
On 07/07/2014 10:58 AM, Ivan Zhakov wrote:
> My technical opinion that FSFS7/log addressing is slower by design,
> because it's doing more (read index, then read data instead of just
> read data) and only caching makes them comparable on performance to
> FSFS6 repositories.
I'm coming into this ki
On 1 July 2014 03:27, Johan Corveleyn wrote:
> On Mon, Jun 30, 2014 at 6:21 PM, Ivan Zhakov wrote:
>> On 30 June 2014 18:51, Stefan Fuhrmann wrote:
>>> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov wrote:
On 19 June 2014 14:21, Ivan Zhakov wrote:
> Hi,
>
> I've performe
On Mon, Jun 30, 2014 at 6:21 PM, Ivan Zhakov wrote:
> On 30 June 2014 18:51, Stefan Fuhrmann wrote:
>> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov wrote:
>>>
>>> On 19 June 2014 14:21, Ivan Zhakov wrote:
>>> > Hi,
>>> >
>>> > I've performed several FSFS performace tests using latest Subversion
On 30 June 2014 18:51, Stefan Fuhrmann wrote:
> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov wrote:
>>
>> On 19 June 2014 14:21, Ivan Zhakov wrote:
>> > Hi,
>> >
>> > I've performed several FSFS performace tests using latest Subversion
>> > from trunk@r1602928.
>> >
>> I've re-ran my FSFS perfor
On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov wrote:
> On 19 June 2014 14:21, Ivan Zhakov wrote:
> > Hi,
> >
> > I've performed several FSFS performace tests using latest Subversion
> > from trunk@r1602928.
> >
> I've re-ran my FSFS performance tests with trunk@r1605444 using latest
> fsfs7 perfo
On Sat, Jun 21, 2014 at 5:18 PM, Branko Čibej wrote:
> On 20.06.2014 11:22, Ivan Zhakov wrote:
>
> On 19 June 2014 17:06, Stefan Fuhrmann
> wrote:
>
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one
On 21.06.2014 17:18, Branko Čibej wrote:
> On 20.06.2014 11:22, Ivan Zhakov wrote:
>> On 19 June 2014 17:06, Stefan Fuhrmann wrote:
>>> Turn out that the ruby repo is something special
>>> in that it has very deep histories of relatively few,
>>> very small files combined with one huge changelog
>
On 20.06.2014 11:22, Ivan Zhakov wrote:
> On 19 June 2014 17:06, Stefan Fuhrmann wrote:
>> Turn out that the ruby repo is something special
>> in that it has very deep histories of relatively few,
>> very small files combined with one huge changelog
>> file (the latter taking up ~75% of the repo).
On 20 June 2014 12:33, Stefan Fuhrmann wrote:
> On Thu, Jun 19, 2014 at 12:21 PM, Ivan Zhakov wrote:
>>
>> Hi,
>>
>> I've performed several FSFS performace tests using latest Subversion
>> from trunk@r1602928.
>>
>> Please find results bellow. I'm also attaching results as a table in
>> pdf for e
On Thu, Jun 19, 2014 at 12:21 PM, Ivan Zhakov wrote:
> Hi,
>
> I've performed several FSFS performace tests using latest Subversion
> from trunk@r1602928.
>
> Please find results bellow. I'm also attaching results as a table in
> pdf for easier reading.
>
> Environment:
> Windows Server 2012 R2 (
> Can you guys dig a little bit deeper here? Seems the performance
> regression that Ivan is seeing deserves some more investigation. With
> Ivan testing http: (and file:) on Windows, and Stefan testing svn: on
> Linux (with different cache settings) it's hard to see where the
> regression comes fr
On 19 June 2014 17:06, Stefan Fuhrmann wrote:
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75% of the repo). See
> below for details.
>
> Also, please not
On Thu, Jun 19, 2014 at 5:06 PM, Stefan Fuhrmann
wrote:
>
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75% of the repo). See
> below for details.
>
> Also
On Thu, Jun 19, 2014 at 11:38 PM, Branko Čibej wrote:
> On 19.06.2014 17:06, Stefan Fuhrmann wrote:
>
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75
On 19.06.2014 17:06, Stefan Fuhrmann wrote:
> Turn out that the ruby repo is something special
> in that it has very deep histories of relatively few,
> very small files combined with one huge changelog
> file (the latter taking up ~75% of the repo). See
> below for details.
>
> Also, please note t
Turn out that the ruby repo is something special
in that it has very deep histories of relatively few,
very small files combined with one huge changelog
file (the latter taking up ~75% of the repo). See
below for details.
Also, please note that your exports contained
>50 files. Using 16MB of c
I'm missing a few points here:
* what were the exact commands run?
* how did you configure your server?
* did you clean disk caches between runs?
* were both, client and server, run on the same VM?
On Thu, Jun 19, 2014 at 12:21 PM, Ivan Zhakov wrote:
> Hi,
>
> I've performed several FSFS perf
Hi,
I've performed several FSFS performace tests using latest Subversion
from trunk@r1602928.
Please find results bellow. I'm also attaching results as a table in
pdf for easier reading.
Environment:
Windows Server 2012 R2 (x64)
2 GB RAM, with 2 virtual processors hosted on Macbook with SSD disk
29 matches
Mail list logo
