From dev-return-19955-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Wed Jan 25 17:49:42 2012
Return-Path:
X-Original-To: apmail-openjpa-dev-archive@www.apache.org
Delivered-To: apmail-openjpa-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id 71E3A96E4
for ; Wed, 25 Jan 2012 17:49:42 +0000 (UTC)
Received: (qmail 27521 invoked by uid 500); 25 Jan 2012 17:49:42 -0000
Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org
Received: (qmail 27451 invoked by uid 500); 25 Jan 2012 17:49:41 -0000
Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm
Precedence: bulk
List-Help:
List-Unsubscribe:
List-Post:
List-Id:
Reply-To: dev@openjpa.apache.org
Delivered-To: mailing list dev@openjpa.apache.org
Received: (qmail 27442 invoked by uid 99); 25 Jan 2012 17:49:41 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jan 2012 17:49:41 +0000
X-ASF-Spam-Status: No, hits=1.5 required=5.0
tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS
X-Spam-Check-By: apache.org
Received-SPF: pass (nike.apache.org: domain of kwsutter@gmail.com designates 209.85.215.46 as permitted sender)
Received: from [209.85.215.46] (HELO mail-lpp01m010-f46.google.com) (209.85.215.46)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 25 Jan 2012 17:49:34 +0000
Received: by lagu2 with SMTP id u2so1221586lag.33
for ; Wed, 25 Jan 2012 09:49:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:content-type;
bh=/RpzlJCmP7UKoG++Ax/J+3aK9aWD8ZrU186zoxCpR/c=;
b=f+qBYx/1qApLJGEJRi5kwfSEGB4E4IRSosW6xNP1WBQ12SM3rh4FW9mY8YFMP9vSSe
nkk3Eaqjg2f6bnHD3xhhyZWRVotlwisYdLWIv8f9+hlEzrxqzlbmOSEtGHVdNw9Siy6g
Tiw3KKoej9mYzCbG+CV4ZO1e3ywrNeVwLqr00=
Received: by 10.112.83.42 with SMTP id n10mr4621208lby.101.1327513753453; Wed,
25 Jan 2012 09:49:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.112.30.226 with HTTP; Wed, 25 Jan 2012 09:48:52 -0800 (PST)
In-Reply-To: <4F202408.5010101@apache.org>
References: <4F1EABE3.5010809@apache.org>
<4F202408.5010101@apache.org>
From: Kevin Sutter
Date: Wed, 25 Jan 2012 11:48:52 -0600
Message-ID:
Subject: Re: H2 poor performance?
To: dev@openjpa.apache.org
Content-Type: multipart/alternative; boundary=f46d0401fc41b585a604b75de1f5
X-Virus-Checked: Checked by ClamAV on apache.org
--f46d0401fc41b585a604b75de1f5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
That is interesting data, Francesco. Since the actual query processing
seems to take less time with H2 (vs MySQL), but the overall time of the
test takes more time with H2 (vs MySQL), my next guess is with Connection
management. Maybe the cost of creating Connections is much more expensive
with H2. I would also lump in the creation of the EntityManagers, but that
should be constant between H2 and MySQL. Except for the creation and
management of the database Connection.
So, you could try a couple of things. One thing would be to utilize DBCP
for pooling your Connections [1]. OpenJPA does not provide connection
pooling. We rely on DBCP or an Application Server to provide that level of
function. After the initial creation of the Connections, then the pooling
and sharing of connections would be a constant between H2 and MySQL.
Depending on your test application, the other thing you might try is the
use of the ConnectionRetainMode set to "always" [2]. If you are constantly
deleting and re-creating EMs, then this property may not be of use. But,
if you are using a single EM for your tests, then keeping a single
Connection around should help with your overall through-put.
Good luck,
Kevin
[1]
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_i=
ntegration_dbcp
[2]
http://openjpa.apache.org/builds/latest/docs/manual/manual.html#ref_guide_d=
bsetup_retain
2012/1/25 Francesco Chicchiricc=F2
> On 24/01/2012 15:54, Kevin Sutter wrote:
>
>> First of all, Congratulations on your migration from Hibernate to OpenJP=
A.
>> I'm glad to hear that things worked out well for you during this effort=
.
>>
>
> Hi Kevin,
> thanks for your answer.
>
>
> As far as H2 performance... My guess is that the H2 Dictionary may not
>> have been kept up to date with improvements to H2 features and SQL
>> improvements. These dictionaries have been maintained as needs arise an=
d
>> as expertise provides input and feedback. For example, our DB2 customer=
s
>> provide input for the DB2 dictionary, Oracle users provide input for the
>> Oracle dictionary, etc. I looked back on my notes and I don't see an
>> expert identified for H2. Would you like to provide that service? :-)
>>
>
> Well, I am not an H2 expert at all: I am just using it for integration
> tests...
> Anyway, if I ever find something interesting on this topic, be sure that
> I'll do my best for providing an adequate patch ;-)
>
>
>
> Since the performance of MySQL and Postgres seem to be acceptable, I wou=
ld
>> assume that the deficiencies are probably localized to the dictionary. =
I
>> would start by turning on Trace while running your test bucket. The ful=
l
>> Trace output will show the timings for executing the various SQL. Maybe
>> you'll find SQL being generated that is not efficient for H2. You could
>> also review the H2 Dictionary and see if some of the basic properties ma=
y
>> not be set correctly for H2. Maybe comparing MySQL and/or Postgres
>> dictionaries and trace output with H2's.
>>
>
> Following your advices, I've put log4jdbc [2] at work and found that,
> quite interestingly, the total time spent in querying H2 is quite less th=
an
> the total time spent in querying MySQL.
> Since, as said before, the total time taken by tests is less with MySQL
> than with H2, I think that there must be some kind of latency.
>
> Does this say something more?
>
> Thanks.
> Regards.
>
>
> 2012/1/24 Francesco Chicchiricc=F2
>> >
>>
>> Hi all,
>>> I am currently facing some strange behavior with in-memory H2.
>>>
>>> In my project - Syncope Open Source IdM [1] - we recently moved from
>>> Hibernate to OpenJPA: everything is now working and I can safely say
>>> that the porting is functionally complete.
>>>
>>> Our source code does some integration tests with Tomcat 7 and an
>>> in-memory H2 instance: unfortunately H2 performs really bad in such
>>> circumstances. Only consider that all tests take 128 secs to run, while
>>> same tests take only 96 secs with PostgreSQL and 77 with MySQL.
>>>
>>> When running the same test suite against last Hibernate-based build, it
>>> turns out instead that H2 is faster than MySQL and PostgreSQL (as I
>>> would expect given the small test dataset).
>>>
>>> Is there anything special I should take care of when using in-memory H2=
?
>>>
>>> TIA.
>>> Regards.
>>>
>>> [1] http://www.syncope-idm.org
>>>
>> [2] http://code.google.com/p/**log4jdbc/
>
>
> --
> Francesco Chicchiricc=F2
>
> Apache Cocoon Committer and PMC Member
> http://people.apache.org/~**ilgrosso/
>
>
--f46d0401fc41b585a604b75de1f5--