[
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
