db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mamta Satoor <msat...@gmail.com>
Subject Re: Thread on Derby on The Server Side
Date Thu, 11 Aug 2005 08:11:08 GMT
Yes, I was referring to Embedded driver.
 Mamta

 On 8/10/05, Jonathan Eric Miller <jemiller@uchicago.edu> wrote: 
> 
> I could be wrong too, but, from what I remember (I did this testing 
> several
> months ago), it was a pretty huge difference. If I remember correctly, I
> found that Derby was noticeable slower than other native DBMSs like MySQL,
> but, if I used batch updates, it had a substantial speed increase and was
> then comparable in speed to the other DBMSs. From what I remember the IBM
> JDBC driver chewed up way more memory than the MySQL and other drivers. 
> e.g.
> if I ran the app with the IBM driver, it would consume say 150 MB RAM,
> whereas it would only use say 35 MB RAM when using MySQL (processing the
> same data and starting with a fresh database).
> 
> I was using the IBM JDBC driver and not the embedded driver. I don't know 
> if
> maybe you were referring to the embedded driver or not...
> 
> Jon
> 
> ----- Original Message -----
> From: "Mamta Satoor" <msatoor@gmail.com>
> To: "Derby Discussion" <derby-user@db.apache.org>
> Sent: Wednesday, August 10, 2005 12:06 AM
> Subject: Re: Thread on Derby on The Server Side
> 
> 
> Hi Jon,
> Looking at the code, I don't think Derby does anything special for batch
> updates. org.apache.derby.impl.jdbc.EmbedStatement.executeBatch() method
> simply executes one statement in the batch at a time. This is from a quick
> look at the code and hence I could be mistaken.
> Mamta
> 
> On 8/9/05, Jonathan Eric Miller <jemiller@uchicago.edu> wrote:
> >
> > From what I remember, I found that if you're doing batch updates, using
> > JDBC
> > batch updates improves performance greatly with Derby. Using
> > PreparedStatements alone was much slower than other DBMSs such as MySQL 
> or
> > MSSQL.
> >
> > Jon
> >
> > ----- Original Message -----
> > From: "David Van Couvering" <David.Vancouvering@Sun.COM>
> > To: "Derby Discussion" <derby-user@db.apache.org>
> > Sent: Tuesday, August 09, 2005 11:24 AM
> > Subject: Re: Thread on Derby on The Server Side
> >
> >
> > > Thanks, Sunitha, for looking into this! It would be *great* if you
> > > posted this to the server side in response to the "Derby is slow"
> > > judgement out there. If for whatever reason you are uncomfortable
> > > doing this, let me know, and I'll be happy to do it with your OK.
> > >
> > > These seem to be the two most common mistakes: assuming a database is
> > > transactional when it's not really (doesn't sync to disk) and not
> > > preparing statements. We ran into this at Sun as well with a group 
> doing
> > > performance tests of Derby.
> > >
> > > We should have a "cheat sheet" for things people should look at when
> > > doing internal benchmarking of Derby and make sure it's front and 
> center
> > > on our web site...
> > >
> > > David
> > >
> > > Sunitha Kambhampati wrote:
> > >
> > >> I took a quick look at the benchmark at polepos that is mentioned in
> > >> the thread on theserverside , specially the bahrain test. This test
> > >> uses Statements instead of PreparedStatement for the select queries.
> > >> ( see BahrainJdbc.java where select queries are like "select * from
> > >> bahrain where LicenseID=" + i
> > >> One important performance tip is to use PreparedStatement with
> > >> dynamic markers instead of Statements. This can show considerable
> > >> improvements.
> > >> If you use Statement with literal values as in the case above, that
> > >> will involve derby having to compile a query plan for each of the
> > >> statements which affects performance. Using PreparedStatement with
> > >> dynamic markers ('?') avoids unnecessary compilation cost , and thus
> > >> faster.
> > >>
> > >> So for example - if you are executing the query above(in 1st para)
> > >> with different LicenseID values, using a Statement will involve
> > >> compilation cost for each statement executed. But in case of
> > >> PreparedStatement, the query would be ' select * from bahrain where
> > >> LicenseID=?" and the statement is compiled only the first time or 
> when
> > >> the optimizer thinks the plan is stale.
> > >>
> > >> Check out the tuning manual for more details :-
> > >> http://db.apache.org/derby/docs/dev/tuning/ctunperf18705.html
> > >>
> > 
> http://db.apache.org/derby/docs/dev/tuning/ctundepth29804.html#ctundepth29804
> > >>
> > >>
> > >> ---------
> > >> Also I think, sometimes default behaviors of databases are different
> > >> and this can lead to different performance out of the box - some key
> > >> factors such as the default isolation level, I/O syncs on a commit or
> > >> not. When I looked at the docs for HSQLDB and Pointbase last, I saw
> > >> that by default they dont force a sync call to the disk on a commit.
> > >> Sunitha.
> > >>
> > >> ps: There are some more differences documented in Derby-110 comments,
> > >> and also in Dan's blog entry.
> > >>
> > 
> http://www-128.ibm.com/developerworks/blogs/dw_blog.jspa?roll=-6&blog=397
> > >>
> > >>>
> > >>> Daniel Noll wrote:
> > >>>
> > >>>> David Van Couvering wrote:
> > >>>>
> > >>>>> Note there are suggestions Derby is slow. If anyone wants to
chime
> > >>>>> in on some of this, that would be great. We don't want the
"word"
> > >>>>> to get out that Derby is slow if it's based on poorly designed
> > >>>>> benchmarks or misconceptions...
> > >>>>>
> > >>>>> http://www.theserverside.com/news/thread.tss?thread_id=35729
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Derby does have an inexplicable 8-12 second wait when creating
or
> > >>>> opening a database where HSQLDB has no noticeable wait, which
> > >>>> doesn't hurt on a server but on a desktop client it's a bit of
a
> > >>>> problem. It really makes our unit tests grind too, since we use
a
> > >>>> fresh database for each test case.
> > >>>>
> > >>>> But that being said, at runtime (which is normally what matters)
we
> > >>>> haven't encountered any noticeable slowdown using Derby over 
> HSQLDB.
> > >>>>
> > >>>> Maybe someone has some quantitative figures though, instead of

> these
> > >>>> qualitative experiences.
> > >>>>
> > >>>> Daniel
> > >>>>
> > >>
> > >
> >
> >
> 
>

Mime
View raw message