db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3092) Use java.util.concurrent in TransactionTable and XactFactory to improve scalability
Date Wed, 02 Dec 2009 23:04:20 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-3092:

    Attachment: xact-concept.png

For the record, I'm attaching a graph showing the results from my test run (xact-concept.png).

I ran the test as

  java org.apache.derbyTesting.perf.clients.Runner -load sr_select_multi -wt 20 -rt 40 -threads

The sr_select_multi client works on a set of 32 tables with a single row in them, with each
client thread randomly picking tables to read from. (The large set of tables eliminates the
data contention that would have been seen if all threads read from the same table. With a
small number of tables, data contention would have been the dominating scalability bottleneck,
and the issues in the transaction table would not be observable.)

> Use java.util.concurrent in TransactionTable and XactFactory to improve scalability
> -----------------------------------------------------------------------------------
>                 Key: DERBY-3092
>                 URL: https://issues.apache.org/jira/browse/DERBY-3092
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions:
>            Reporter: Dyre Tjeldvoll
>         Attachments: xact-concept.diff, xact-concept.png
> Running scalability tests with the client and buffer manager from DERBY-2911 shows that
access to the TransactionTable.trans (a Hashtable) and XactFactory.tranId (a shared long)
are the next major sources of contention. 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message