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

Knut Anders Hatlen updated DERBY-2911:
--------------------------------------

    Attachment: perftest.stat
                perftest.diff

The attached patch merges the test clients used previously in this issue and 
places them under org.apache.derbyTesting.perf.clients. With the class Runner 
in that package, one can start each of the tests from the command line and 
configure which type of load generator (back-to-back or Poisson) to use.

I am currently running tests which compare the performance of ConcurrentCache 
and Clock on one dual-CPU machine and on one 8-CPU machine. I'll post the 
results once I have them.

> Implement a buffer manager using java.util.concurrent classes
> -------------------------------------------------------------
>
>                 Key: DERBY-2911
>                 URL: https://issues.apache.org/jira/browse/DERBY-2911
>             Project: Derby
>          Issue Type: Improvement
>          Components: Performance, Services
>    Affects Versions: 10.4.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: cleaner.diff, cleaner.tar, d2911-1.diff, d2911-1.stat, 
> d2911-10.diff, d2911-10.stat, d2911-11.diff, d2911-2.diff, d2911-3.diff, 
> d2911-4.diff, d2911-5.diff, d2911-6.diff, d2911-6.stat, d2911-7.diff, 
> d2911-7a.diff, d2911-9.diff, d2911-9.stat, d2911-entry-javadoc.diff, 
> d2911-unused.diff, d2911-unused.stat, d2911perf.java, derby-2911-8.diff, 
> derby-2911-8.stat, perftest.diff, perftest.stat, perftest6.pdf, 
> poisson_patch8.tar
>
>
> There are indications that the buffer manager is a bottleneck for some types 
> of multi-user load. For instance, Anders Morken wrote this in a comment on 
> DERBY-1704: "With a separate table and index for each thread (to remove latch 
> contention and lock waits from the equation) we (...) found that 
> org.apache.derby.impl.services.cache.Clock.find()/release() caused about 5 
> times more contention than the synchronization in LockSet.lockObject() and 
> LockSet.unlock(). That might be an indicator of where to apply the next push".
> It would be interesting to see the scalability and performance of a buffer 
> manager which exploits the concurrency utilities added in Java SE 5.

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

Reply via email to