On Mon, Jun 30, 2014 at 6:21 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
> On 30 June 2014 18:51, Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com> wrote:
>> On Mon, Jun 30, 2014 at 4:06 PM, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>>
>>> On 19 June 2014 14:21, Ivan Zhakov <ivan_at_visualsvn.com> wrote:
>>> > Hi,
>>> >
>>> > I've performed several FSFS performace tests using latest Subversion
>>> > from trunk_at_r1602928.
>>> >
>>> I've re-ran my FSFS performance tests with trunk_at_r1605444 using latest
>>> fsfs7 performance fixes including combining indexes to revision files.
>>
>>
> [..]
>
>> Also, it seems that some of these tests are run from hot
>> caches - causing a lot of variation and making comparison
>> pointless. An extreme case:
>>
>> ptime 1.0 for Win32, Freeware - http://www.pc-tools.net/
>> Copyright(C) 2002, Jem Berkes <jberkes_at_pc-tools.net>
>>
>> === "svn log http://localhost/svn/ruby-fsfs6-unpacked >nul" ===
>>
>> Execution time: 216.064 s
>> ...
>> Execution time: 13.268 s
>> ...
>> Execution time: 18.061 s
>>
> Yes, I use hot caches and already noted this in my report: "Every test
> was run 3 times and only two latest used"
>
> I don't see the reason to test on cold disk caches because I assume
> that caches in the real servers are somewhat hot. No matter how it's
> complex to compare the results on hot disk caches. For me, log
> addressing feature is definitely useless if it slower on hot disk
> caches.
Innocent bystander's opinion: I appreciate your critical look at the
performance of fsfs7, Ivan, but I disagree. I think in lots of
real-world cases cold cache performance is much more important than
hot cache performance.
Especially in a big / busy repository and for use cases such as "svn
log". I usually don't ask the same "svn log" three times in a row.
User A might request "svn log" of some file or subtree, user B then
asks for another subtree, and so on. It's the performance of that
first (and usually only) request that matters most to me.
Same for export: different users export different parts of the
repository all the time. Not the same part a couple of times in a row
(except perhaps right after some release / milestone / ...).
So I for one am more interested in cold-cache performance
improvements, even if they come at a (hopefully small) hot-cache
performance cost.
OTOH, I do wonder about these (hot-cache) performance regressions ...
maybe they can still be improved?
--
Johan
Received on 2014-07-01 01:28:38 CEST