"Anders Morken (JIRA)" <[EMAIL PROTECTED]> writes: > Anders Morken commented on DERBY-1704: > -------------------------------------- > > In slightly related work, we've recently done a little testing with > a single-record select load on a trunk patched with DERBY-2107 as > well as a port of the patches to split the hash tables in the lock > subsystem that you included here. > > With a separate table and index for each thread (to remove latch > contention and lock waits from the equation) we got an overall > throughput increase of about 16% compared to a "single table for all > threads" run (given a cache large enough to maintain the database > in-memory), and 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 - and validates the "split > hashtable" approach for this workload. =)
Thank you for running the tests and posting your findings! I think you're right that Clock will be the next bottleneck for multi-threaded applications. It's a big hash table which all threads need to synchronize on, very similar to the current lock manager. -- Knut Anders
