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