[
https://issues.apache.org/jira/browse/DERBY-646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676272#action_12676272
]
Kristian Waagan commented on DERBY-646:
---------------------------------------
We now have two candidate solutions. How do we proceed?
I would very much like to get an in-memory back end included in the upcoming
10.5 release. In my opinion this should be pretty safe, as almost no existing
code is modified and the user has to take an active step to use the in-memory
back end.
To start mapping the performance characteristics of the two solutions, I ran
some of the performance tests we have. Note that these are based on only a few
runs, and a run time of 60 seconds only (pluss 30 seconds warmup). The numbers
are average tps (transactions per second).
There is some variation in the tests, so where the numbers differ only by a very
small percentage, I think we can assume the performance is comparable for now.
Hardware #1: 32 hardware execution threads, 1200 MHz.
sr_update sr_select bank_tx
1 thread
memory 1963 3059 823
vfmem 2307 3753 878
8 threads
memory 7662 14321 2163
vfmem 12692 17695 2294
32 threads
memory 7357 13984 2076
vfmem 12219 16546 2144
Hardware #2: Dual core Opteron, 2.4 GHz
sr_update sr_select bank_tx
1 thread
memory 12257 20295 5123
vfmem 12288 20657 5189
4 threads
memory 15064 32117 6120
vfmem 15857 32629 6115
8 threads
memory 16682 31257 5767
vfmem 16357 31361 5775
Hardware #3: 2xDual core Opteron, 2.8 GHz
sr_update sr_select bank_tx
1 thread
memory 13548 22184 5805
vfmem 13705 21770 5765
4 threads
memory 29019 57861 10443
vfmem 29727 58053 10479
8 threads
memory 26348 46580 9372
vfmem 26676 46805 9347
16 threads
memory 24500 44249 8976
vfmem 24883 43832 9014
Hardware #2: Dual core Opteron, 2.4 GHz, sr_update, page cache size
40 1000 15000
1 thread
memory 9932 12234 19207
vfmem 10075 12223 18995
8 threads
memory 12898 16540 26393
vfmem 13148 16662 28017
Hardware #2: Dual core Opteron, 2.4 GHz, sr_update, page size
Page cache size | 40 | | 1000 |
4 KB 32 KB 4 KB 32 KB
1 thread
memory 9902 2902 12369 20168
vfmem 10342 3247 12059 19801
8 threads
memory 12926 3599 16523 27333
vfmem 13261 4059 16592 28361
As far as I can see from these simple performance tests, the only configuration
where the two solutions differs significantly, is when running on a CMT (chip
multi threading) machine. Of the loads I have tested, this is most clearly
visible with update load.
I have not investigated this further.
Another thing one could look into, is the memory usage of the two solutions.
> In-memory backend storage support
> ---------------------------------
>
> Key: DERBY-646
> URL: https://issues.apache.org/jira/browse/DERBY-646
> Project: Derby
> Issue Type: New Feature
> Components: Store
> Environment: All
> Reporter: Stephen Fitch
> Attachments: derby-646-1a-raw-compiles.diff,
> derby-646-1a-raw-compiles.stat, derby-646-20090222.diff,
> derby-646-20090222.stat, derby-646-2a-vfmem_first_rev.diff,
> derby-646-2a-vfmem_first_rev.stat, svn.diff
>
>
> To allow creation and modification of databases in-memory without requiring
> disk access or space to store the database.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
