All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans Reiser <reiser@namesys.com>
To: David Dabbs <david@dabbs.net>
Cc: reiserfs-list@namesys.com
Subject: Re: mongo benchmark results
Date: Sun, 25 Jul 2004 23:48:19 -0700	[thread overview]
Message-ID: <4104A933.7020509@namesys.com> (raw)
In-Reply-To: <20040726055047.E145F15C29@mail03.powweb.com>

David Dabbs wrote:

>At http://dabbs.net/reiser4/mongo.html I've posted some benchmarks from my
>aging but available test box. All numbers were generated with the Namesys
>mm7 snapshot. The "A.INFO_R4=new" are results from a reiser4 with modified
>comparison functions as well as znode_contains_key_strict(). So, here are my
>questions:
>
>Do these results appear consistent with others' recent benchmarking? 
>  
>
Increase file_size to 8k, and then we can compare.  This will reduce 
reiser4's space savings from 19% to 9%, but it will probably increase 
performance.

Your work had a remarkable effect on the create phase.  Very good work.  
I don't know why the impact was not larger for the stats phase.

Elena, please reproduce his results on our hardware.

>Should I be using particular mount options during benchmarking?
>I would think running mongo would be necessary to ensuring that reiser4 mods
>are 'safe,' but it is sufficient?
>Viz the prior question, is there a recommended test regimen or regression
>suite?
>
>
>I started to dig into mongo a bit and noticed that it does not appear to
>vary the file & dir _names_ it generates. Most appear to be ~7 characters
>long with a pattern of 'f' followed by some number. Isn't this a) atypical
>of file/dir name distribution and b) favorable to/biased towards the "short
>name" code? IOW, if R4_LARGE_KEYS is the default and all generated test file
>names' lengths < 15 characters,
>
You are encouraged to survey filesystems and supply a realistic filename 
generator.

In practice, most filenames are less than 15 characters. 

Another thing we need to do is add a file data generator that is based 
on slicing and dicing a linux kernel tarball, because we won't be able 
to do a good benchmark of the compression code until we do so.

> then the large file name code is not being
>covered or benchmarked. Perhaps I'm mixing apples and oranges (code coverage
>and benchmarking). 
>
>
>Just curious,
>
>David
>
>
>
>
>
>  
>


  reply	other threads:[~2004-07-26  6:48 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-26  5:49 mongo benchmark results David Dabbs
2004-07-26  6:48 ` Hans Reiser [this message]
2004-07-26  8:24   ` Nikita Danilov
2004-07-26  8:43     ` Alex Zarochentsev
2004-07-25  8:21       ` Nikita Danilov
2004-07-26 11:01         ` Alex Zarochentsev
2004-07-26  8:54       ` Alex Zarochentsev
2004-07-26 17:08   ` Alex Zarochentsev
2004-07-26 17:31     ` David Dabbs
2004-07-26 19:11       ` Hans Reiser
2004-07-26 19:45         ` David Dabbs
2004-07-26 19:18       ` Hans Reiser
     [not found]         ` <41056FFF.4010208@namesys.com>
     [not found]           ` <4105FDFA.1090308@namesys.com>
     [not found]             ` <410833F9.501@namesys.com>
2004-07-29  7:31               ` Reiser4 slowed down, Elena has found the changesets responsible, we will fix it Hans Reiser
     [not found]               ` <20040729152103.GN4881@backtop.namesys.com>
     [not found]                 ` <410A57C6.3020501@namesys.com>
2004-07-30 18:28                   ` Reiser4 performance is almost completely restored now Hans Reiser
2004-07-26 19:41       ` mongo benchmark results E. Gryaznova
2004-07-26 20:00         ` David Dabbs
2004-07-26 20:06           ` E. Gryaznova
2004-07-29  3:13             ` David Dabbs
2004-07-30 15:16               ` E. Gryaznova
2004-07-30 16:11                 ` David Dabbs
2004-07-30 18:57                 ` Reiser4 performance is almost completely restored now David Dabbs
2004-07-30 19:01                   ` Alex Zarochentsev
2004-07-30 20:37                 ` Unattended mongo benchmark? David Dabbs
2004-07-31  5:19                   ` Hans Reiser
2004-07-31 11:00                     ` Nikita Danilov
2004-07-31 14:16                       ` David Dabbs
2004-07-30 21:46                         ` Nikita Danilov
2004-07-31 14:46                         ` Vladimir V. Saveliev
2004-07-30 21:59                           ` Nikita Danilov
2004-07-31 15:13                             ` David Dabbs
2004-07-31 16:48                               ` Vladimir V. Saveliev
2004-07-27  7:20         ` mongo benchmark results Hans Reiser

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4104A933.7020509@namesys.com \
    --to=reiser@namesys.com \
    --cc=david@dabbs.net \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.