db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-465) Embedded Derby-PointBase comparison
Date Thu, 21 Jul 2005 18:40:46 GMT
    [ http://issues.apache.org/jira/browse/DERBY-465?page=comments#action_12316402 ] 

Mike Matrigali commented on DERBY-465:
--------------------------------------

1)   I look forward to your subsequent posting the files you are using get your results. 
It seems important when publishing
      performance results to make it possible for others to reproduce your work.
      This will also help me be able to understand the problems you are running into.

2) For multi-user read tests, given that the results are for 100 cyles, which means each thread
is retrieving 100*100,000 rows, then the
     numbers for Derby seem at least to be the right order of magnitude.  The 10 user number
is a little slower than I would have guessed,
     I was hoping for somthing in the range of 3 times the 2 user number. 
     We see approximately 100,000 rows/second for a single thread.  If you plan on doing
     any more runs, here are the thread numbers I would use for a 4 processor machine: 1,
2, 3, 4, 8, 16.  These numbers can show
     better how the tested db is scaling across the available processors.  Especially for
the select run
     I would expect Derby to have relatively flat elapsed time from 2,3,4 and then start to
see a steady increase as more threads are
     added.

     Are you sure there were no problems with your PB runs?  It definitely seems strange that
the 1 user run is more than the 2, 5, and
     10 user runs.  And retrieving and processing 10,000,000 rows in 1 second seems unlikely.
  In my work in the past sometimes 
     I would get problems in my setup and get results like this, and not see them in the program
especially if like in your tests there
     is no sanity checking to see that the expected number of rows are processed and/or the
right results are returned.

3) from description of tests or the included source code I could not tell the following:
     o are multi-user tests auto commit or not in the delete/update phase.
     o if they are not auto commit, when does the commit happen?  I think the isAutoCommit
flag is set in a module that you have not posted.

4) lock escalation/timeout issues
     o I can answer better once I know answer to 3, but I am going to assume the test is not
auto commit as you are committing
        the insert every 10 rows, so am going to assume the update and delete happen in on
transaction.  
     o As you found your test happened to exactly match the lock escalation threshhold.  For
best multi-user operation I suggest you 
         raise the lock escalation threshhold to something like 10000.
     o In answer to your question, derby will attempt to escalate to table locking once it
reaches the threshold, but if it can't get the 
         the table level lock then it will continue to get row locks - it was decided it was
better to continue to use more memory rather
         than fail the statement at this point.  This process is time consuming so for better
performance if you 
         expect an application to run concurrently and get more that 5000 locks it is recommended
you raise the escalate threshhold.
        It would seem in your concurrent application, that escalation other than the single
user case is almost never possible (but is totally timing dependent).
        So as expected the update or delete is waiting on a row lock that is blocked because
another thread has the row locked 
        for longer than the lock timeout threshhold.   

        I am not sure if somehow your program is not committing as expected, or if without
an appropriate index the update and delete operations
        are taking too long, causing time outs in other threads waiting on them.  To debug
this issue I recommend using the above mentioned faq to
        enable printing the lock table when the timeout occurs - but warn that it is probably
going to be very large with 1000's of row locks.

5) To get a more direct comparison would you consider running pointbase with log.forcewrite=true.
 This is especially appropriate if your target 
     application depends on the recoverability of committed transactions.  

> Embedded Derby-PointBase comparison
> -----------------------------------
>
>          Key: DERBY-465
>          URL: http://issues.apache.org/jira/browse/DERBY-465
>      Project: Derby
>         Type: Wish
>   Components: Test
>     Versions: 10.0.2.1, 10.0.2.0
>  Environment: Windows Server 2003, 4 processors, summary CPU 3.00 Ghz, RAM 1 Gb
>     Reporter: Peter Kovgan
>  Attachments: Benchmarks_info_independent.doc, DBOperations.java, Multithreading-access
read.doc, User.java, derby-optimization.doc, derby-pb1.doc
>
> I have tested 4 major embedded DB.
> I have found that major disadvantage of Derby is 
> 1)low insert speed and 
> 2)significant performance degradation in select, update, delete  operation speed starting
from some table size.
> PointBase in comparison has not such degradation.
> It will be better if you improve your product.
> Good luck and thank you.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message