Return-Path: X-Original-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Delivered-To: apmail-jackrabbit-oak-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C5B7CFAA2 for ; Fri, 31 May 2013 12:53:32 +0000 (UTC) Received: (qmail 51631 invoked by uid 500); 31 May 2013 12:53:32 -0000 Delivered-To: apmail-jackrabbit-oak-dev-archive@jackrabbit.apache.org Received: (qmail 51450 invoked by uid 500); 31 May 2013 12:53:29 -0000 Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: oak-dev@jackrabbit.apache.org Delivered-To: mailing list oak-dev@jackrabbit.apache.org Received: (qmail 51412 invoked by uid 99); 31 May 2013 12:53:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 May 2013 12:53:27 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of moore@adobe.com designates 64.18.1.236 as permitted sender) Received: from [64.18.1.236] (HELO exprod6og120.obsmtp.com) (64.18.1.236) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 31 May 2013 12:53:20 +0000 Received: from outbound-smtp-2.corp.adobe.com ([193.104.215.16]) by exprod6ob120.postini.com ([64.18.5.12]) with SMTP ID DSNKUaidKqpk+6+x1LdpG4svsGFdCmjBjjya@postini.com; Fri, 31 May 2013 05:53:00 PDT Received: from inner-relay-2.corp.adobe.com (mail-321.pac.adobe.com [153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r4VCquAI021448 for ; Fri, 31 May 2013 05:52:57 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id r4VCqtw7020601 for ; Fri, 31 May 2013 05:52:55 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Fri, 31 May 2013 05:52:55 -0700 From: "Michael C. Moore" To: "oak-dev@jackrabbit.apache.org" Date: Fri, 31 May 2013 05:52:54 -0700 Subject: RE: Some more benchmarks Thread-Topic: Some more benchmarks Thread-Index: Ac5d+IhiR8uPYjozSjeg2joqasA9ywABOJtw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Virus-Checked: Checked by ClamAV on apache.org Hi Jukka, First, thanks for the information. I think you explained what the numbers = mean (seconds, milliseconds, etc.) in a previous email, but I can't locate = it. Can you briefly explain the test results or point me to a wiki or link that= has the explanation? Thanks, Michael -----Original Message----- From: Jukka Zitting [mailto:jukka.zitting@gmail.com]=20 Sent: Friday, May 31, 2013 8:14 AM To: Oak devs Subject: Re: Some more benchmarks Hi, On Fri, Apr 26, 2013 at 2:12 PM, Jukka Zitting wr= ote: > On Wed, Mar 27, 2013 at 11:41 AM, Jukka Zitting = wrote: >> Here's a few more simple benchmark results to show where we are: > > Updated numbers with latest Oak: And another one: Apache Jackrabbit Oak 0.9-SNAPSHOT # ReadPropertyTest min 10% 50% 90% max = N Jackrabbit 41 41 42 43 90 = 1428 Oak-Default 58 58 59 60 69 = 1018 Oak-Mongo 66 67 67 68 74 = 889 Oak-Segment 278 279 281 285 321 = 213 Oak-Tar 114 114 115 117 136 = 520 # SmallFileReadTest min 10% 50% 90% max = N Jackrabbit 56 57 61 84 194 = 895 Oak-Default 57 57 59 304 353 = 594 Oak-Mongo 148 148 158 406 479 = 304 Oak-Segment 33 33 36 37 73 = 1701 Oak-Tar 15 15 16 18 31 = 3574 # SmallFileWriteTest min 10% 50% 90% max = N Jackrabbit 184 196 248 444 2084 = 115 Oak-Default 136 138 181 433 1789 = 162 Oak-Mongo 595 617 795 1020 1075 = 31 Oak-Segment 156 161 172 225 660 = 100 Oak-Tar 101 102 108 116 270 = 167 (also available at https://gist.github.com/jukka/5684506 if the above gets = mangled with a variable-width font) It looks like we have a performance regression in ReadPropertyTest. Quick profiling shows a lot of the time seems to be going to MemoryNodeBuil= der$ConnectedHead.update(), which is weird since we're only reading and thu= s the related MNB head should be unconnected. I'll investigate. BR, Jukka Zitting