[jira] Updated: (DERBY-3092) Use java.util.concurrent in TransactionTable and XactFactory to improve scalability

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

     [ 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 N

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: 10.3.1.4
>            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.