db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dyre Tjeldvoll (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3092) Use java.util.concurrent in TransactionTable and XactFactory to improve scalability
Date Mon, 01 Oct 2007 09:06:50 GMT

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

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

View raw message