[
https://issues.apache.org/jira/browse/DERBY-3092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531441
]
Dyre Tjeldvoll commented on DERBY-3092:
---------------------------------------
Hi Bryan,
yes, TPS=Transactions Per Second. The client used is the d2911perf.java client
Knut attached to that issue:
https://issues.apache.org/jira/secure/attachment/12365001/d2911perf.java
Yes, those are the numbers I'm seeing, but the client has been carefully
constructed to avoid any "data contention". That is,
each client (connection) selects a single record from its own table. So there
is no contention for locks or latches. It is admittedly a pretty unrealistic
load for a database, but the goal was to identify "non-data-related" contention
in the engine. The idea being that if the engine doesn't scale with this type
of load, it isn't much point in trying to address scalability issues for other
types of load...
> 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: Performance, Store
> Affects Versions: 10.3.1.4
> Reporter: Dyre Tjeldvoll
> Attachments: xact-concept.diff
>
>
> 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.
