[
https://issues.apache.org/jira/browse/DERBY-3024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen closed DERBY-3024.
-------------------------------------
Resolution: Fixed
Fix Version/s: 10.6.1.0
Assignee: Knut Anders Hatlen
I think the problem described in this issue is not completely fixed yet.
However, since some fixes have been committed, and it's not clear what more
needs to be done, I'm closing the issue. If someone later comes up with an idea
on how to improve this code, that work could be tracked in a separate issue.
> Validation of shared plans hurts scalability
> --------------------------------------------
>
> Key: DERBY-3024
> URL: https://issues.apache.org/jira/browse/DERBY-3024
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.4.1.3
> Environment: Sun Java SE 6, Solaris 10, Sun Fire V880 (8 CPUs)
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Priority: Minor
> Labels: derby_triage10_10
> Fix For: 10.6.1.0
>
> Attachments: patch-1a.diff, patch-1a.png, patch-2a.diff,
> patch-2a.png, values1.png, Values.java
>
>
> To investigate whether there was anything in the SQL execution layer that
> prevented scaling on a multi-CPU machine, I wrote a multi-threaded test which
> continuously executed "VALUES 1" using a PreparedStatement. I ran the test on
> a machine with 8 CPUs and expected the throughput to be proportional to the
> number of concurrent clients up to 8 clients (the same as the number of
> CPUs). However, the throughput only had a small increase from 1 to 2 clients,
> and adding more clients did not increase the throughput. Looking at the test
> in a profiler, it seems like the threads are spending a lot of time waiting
> to enter synchronization blocks in GenericPreparedStatement.upToDate() and
> BaseActivation.checkStatementValidity() (both of which are synchronized on
> the a GenericPreparedStatement object).
> I then changed the test slightly, appending a comment with a unique thread id
> to the "VALUES 1" statement. That means the threads still did the same work,
> but each thread got its own plan (GenericPreparedStatement object) since the
> statement cache didn't regard the SQL text strings as identical. When I made
> that change, the test scaled more or less perfectly up to 8 concurrent
> threads.
> We should try to find a way to make the scalability the same regardless of
> whether or not the threads share the same plan.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
