db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From DerbyNovice <clars...@ureason.com>
Subject RE: Derby/HSQLDB major performance difference
Date Tue, 10 Mar 2009 10:43:29 GMT

Hi,

Thanks for the tip.
I reran my test last night with the property set as you suggested but the
output is the same.
The log shows the property being used (see below) but it does not seem to
make a difference.

     1 ?#?#? UrProva.java at line: 219 Dbg-out variable s_dbsize [700000]
      2 ?#?#? UrProva.java at line: 221 Dbg-out variable s_updatesize [30]
      3 ?#?#? UrProva.java at line: 223 Dbg-out variable s_selectsize [100]
      4 ?#?#? UrProva.java at line: 225 Dbg-out variable s_delmodsize [10]
      5 ?#?#? UrProva.java at line: 228 Dbg-out variable driver
[org.apache.derby.jdbc.EmbeddedDriver]
      6 ?#?#? UrProva.java at line: 230 Dbg-out variable protocol
[jdbc:derby:]
      7 ?#?#? UrProva.java at line: 232 Dbg-out variable dbName
[/home/cl/projects/hsqldbprova/derby      7 /xx;create=true]
      8 ?#?#? UrProva.java at line: 236 Dbg-out variable propfilename
[db.prop]
      9 Loaded the appropriate driver
     10 -- listing properties --
     11 derby.system.durability=test
     12 Connected to and created database
/home/cl/projects/hsqldbprova/derby/xx;create=true
     13 Populating db



I think you have a good point here, and it is not always one needs
durability so sacrificing that
for speed makes sense. Any ideas as to why the property does not bite?

Regards,



Jeff Stuckman wrote:
> 
> Hello,
> 
> Did you try setting derby.system.durability=test and rerunning your
> benchmark?
> 
> From what I understand, Derby provides hard guarantees of durability -- if
> there is a power outage, system crash, or disk failure anytime after your
> commit() call has returned, the data is guaranteed to be available when
> your
> system comes back up. To guarantee this durability, Derby needs to work
> around the write caching that your OS will normally perform, which reduces
> performance. This will cause the very long insertion period that you see.
> 
> (Derby even includes support for XA (distributed) transactions, which are
> impossible to properly support without durability guarantees)
> 
> I couldn't find any information on durability on the HSQLDB website, and
> from the performance results that you describe, I'm inclined to believe
> that
> HSQLDB does not make this guarantee. If you set the above property, Derby
> will reduce its durability guarantees and perform faster.
> 
> Jeff
> 
> -----Original Message-----
> From: DerbyNovice [mailto:clarsson@ureason.com] 
> Sent: Friday, March 06, 2009 12:39 PM
> To: derby-user@db.apache.org
> Subject: Derby/HSQLDB major performance difference
> 
> 
> I am using Derby as an embedded db in my swing application. Recently I
> decided to have a go at HSQLDB (cached tables, embedded) to see  how it
> coped. I have written a test program which
> *  inserts a number of records in my db with random keys
> * makes an index on the keys. 
> * runs a number of select statements
> * updates a number of records with new random values.
> 
> At the same time I measure lapse time and memory in a separate thread.
> I made the same run with Derby and with HSQLDB, see the two uploaded
> charts,
> with -Xmx1024m .
> Initially the idea was to see which db was faster, but as soon as I saw
> the
> results I realised there are
> other differences.
> The scale on the x-axis is half seconds, i 1000 is 500 seconds. The scale
> on
> the y-axis is bytes as reported by gc.
> Notice the difference in scale between HSQLDB and derby. I have tried to
> optimise the memory with HSQLDB options
> but it has only marginal difference and it does not change the behaviour.
>  Observations:
> * HSQLDB uses a magnitude more memory than Derby.
> * HSQLDB does not seem to benefit from the indices.
> * HSQLDB is faster in total, but not to the extent the memory usage
> suggests.
> * Derby uses a very long insertion  period but the select statements are
> very fast and memory lean
> * Derby manages the memory during the run, the total memory goes up AND
> DOWN.
> * Derby seems to struggle (timewise) with the inserts (the long slope
> initially) but breeze through the select statements
> which all take less than a second.
> The run shown uses 700000 records, but smaller runs show the same
> behaviour.
> For me this makes HSQLDB useless as it would gradually eat my applications
> memory. Anyone trying to weigh performance benefits between db's should be
> aware of these very different characteristics.
> 
> I'd be pleased if anyone would care to comment on the test run and maybe
> shed some light on the totally different characteristics seen here.
> I'd be happy to upload the timing tests and my program too if there is an
> interest.
> 
> Regards,
> 
> 
> DERBY RUN
> http://www.nabble.com/file/p22377140/mem.gif 
> HSQL RUN
> http://www.nabble.com/file/p22377140/mem.gif 
> -- 
> View this message in context:
> http://www.nabble.com/Derby-HSQLDB-major-performance-difference-tp22377140p2
> 2377140.html
> Sent from the Apache Derby Users mailing list archive at Nabble.com.
> 
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Derby-HSQLDB-major-performance-difference-tp22377140p22431720.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.


Mime
View raw message