CouchDB
  1. CouchDB
  2. COUCHDB-913

Caching of BTree nodes and documents

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Skill Level:
      Regular Contributors Level (Easy to Medium)

      Description

      The following patch adds optional caching of BTree nodes (for both DBs and view indexes) and documents:

      http://github.com/fdmanana/couchdb/commit/c6361d1e0d86942fc86350bea9ca1e8d7539c1b3

      Look at the new parameters introduced in default.ini.tpl.in for more details.

      This is based on the work initially done by Randall Leeds, found at:

      http://github.com/tilgovi/couchdb/commits/forevercache

      I'll not commit it before 1.1 nor without any feedback.
      cheers

        Activity

        Hide
        Filipe Manana added a comment -

        After merging all the latest trunk changes related to performance into couch_append_cache, I ran again 2 more tests to compare it against trunk. Both tests ran for 15 minutes, use documents of 5Kb each and only have the document cache enabled:

        1. couch_append_cache (no btree cache, 8mb doc cache) versus trunk, 5Kb docs

        $ node tests/compare_write_and_read.js --wclients 20 --rclients 200 \
        -name1 couch_cache_8mb_doc -name2 trunk \
        -url1 http://localhost:5984/ -url2 http://localhost:5985/ \
        --duration 900

        http://graphs.mikeal.couchone.com/#/graph/df0f79455c9c600f66d1ce42ea00036a

        1. couch_append_cache (no btree cache, 16mb doc cache) versus trunk, 5Kb docs

        $ node tests/compare_write_and_read.js --wclients 20 --rclients 200 \
        -name1 couch_cache_16mb_doc -name2 trunk \
        -url1 http://localhost:5984/ -url2 http://localhost:5985/ \
        --duration 900

        http://graphs.mikeal.couchone.com/#/graph/df0f79455c9c600f66d1ce42ea001184

        It's now clear that implementing a cache (at least as it is) is definitely not worth.

        Show
        Filipe Manana added a comment - After merging all the latest trunk changes related to performance into couch_append_cache, I ran again 2 more tests to compare it against trunk. Both tests ran for 15 minutes, use documents of 5Kb each and only have the document cache enabled: couch_append_cache (no btree cache, 8mb doc cache) versus trunk, 5Kb docs $ node tests/compare_write_and_read.js --wclients 20 --rclients 200 \ -name1 couch_cache_8mb_doc -name2 trunk \ -url1 http://localhost:5984/ -url2 http://localhost:5985/ \ --duration 900 http://graphs.mikeal.couchone.com/#/graph/df0f79455c9c600f66d1ce42ea00036a couch_append_cache (no btree cache, 16mb doc cache) versus trunk, 5Kb docs $ node tests/compare_write_and_read.js --wclients 20 --rclients 200 \ -name1 couch_cache_16mb_doc -name2 trunk \ -url1 http://localhost:5984/ -url2 http://localhost:5985/ \ --duration 900 http://graphs.mikeal.couchone.com/#/graph/df0f79455c9c600f66d1ce42ea001184 It's now clear that implementing a cache (at least as it is) is definitely not worth.
        Hide
        Filipe Manana added a comment -

        Closing this. The additional complexity and code from caching is not worth the generally insignificant gains (smaller then 5ms).

        Show
        Filipe Manana added a comment - Closing this. The additional complexity and code from caching is not worth the generally insignificant gains (smaller then 5ms).
        Hide
        Filipe Manana added a comment -

        Forgot to mention, the tests done before with caching had an hit rate of about 99.9%.

        Also, 2 relaximation tests with only the documents cache enabled (of size 16Mb):

        (small docs) -> http://graphs.mikeal.couchone.com/#/graph/5c859b3e7d1b9bd0488cfe2711044281

        (large docs) -> http://graphs.mikeal.couchone.com/#/graph/5c859b3e7d1b9bd0488cfe27110439d8

        Show
        Filipe Manana added a comment - Forgot to mention, the tests done before with caching had an hit rate of about 99.9%. Also, 2 relaximation tests with only the documents cache enabled (of size 16Mb): (small docs) -> http://graphs.mikeal.couchone.com/#/graph/5c859b3e7d1b9bd0488cfe2711044281 (large docs) -> http://graphs.mikeal.couchone.com/#/graph/5c859b3e7d1b9bd0488cfe27110439d8
        Hide
        Filipe Manana added a comment -

        All the caching efforts are now in a new branch: https://github.com/fdmanana/couchdb/commits/couch_append_cache

        Basically, I dropped term_cache and created a new cache module couch_cache.erl that is based on term_cache and the existing auth_cache (for faster lookups).

        Most important, I made a fairly detailed analysis, not relying exclusively in relaximation graphs, which are IMO, hard to interpret sometimes.

        Over that branch, I applied this patch: http://friendpaste.com/ZZrIsE8FQ7U2HN1XDiBnj
        This patch adds io:format calls around the cache lookups and file read operations and reports the time spent (in milliseconds) for each of these operations.

        With that patch applied, I ran several times the readers and writers relaximation test with 50 writers, 200 readers for a duration of 5 minutes:

        • 1 ran for small documents (around 1.2Kb each) with caching enabled
        • 1 ran for small documents (around 1.2Kb each) with caching disabled
        • 1 ran for large documents (around 100Kb each) with caching enabled
        • 1 ran for large documents (around 100Kb each) with caching disabled

        I then extracted the relevant messages from the logs (I ran CouchDB with ./utils/run | tee log) like this:
        $ egrep 'btree_cache_' log > 'btree_cache_lookups.txt'
        $ egrep 'btree_file_read' log > 'btree_file_reads.txt'
        $ egrep 'doc_cache_' log > 'small_doc_cache_lookups.txt'
        etc...

        Now, up to the analysis results:

        ==== BTree nodes

        == 859513 cache lookups

        Top 5 frequency:

        $ grep 'btree_cache_hit' btree_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -5
        441509 0.005
        284771 0.004
        72980 0.006
        13761 0.007
        7356 0.008

        ~93% of cache lookups took up to 0.006ms

        10 worst cache lookup times

        $ grep 'btree_cache_hit' btree_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail
        1 20.69
        1 20.828
        1 22.12
        1 22.408
        1 22.668
        1 23.361
        1 25.732
        1 26.346
        1 33.791
        1 37.375

        == 726795 BTree node file reads

        Top 5 frequency

        $ cat btree_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -5
        3742 0.038
        3666 0.037
        3564 0.036
        3331 0.039
        3293 0.044

        $ cat btree_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.06;' | wc -l
        726795

        All BTree node file reads took more than 0.06ms to complete (one order of magnitude superior to 93% of the cache lookups)

        $ cat btree_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.1;' | wc -l
        652910

        ~90% of the BTree node file reads take more than 0.1ms (2 orders of magnitude superior to 93% of the cache lookups)

        $ cat btree_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 1.0;' | wc -l
        453728

        62% of the BTree node file reads took more than 1.0ms (4 orders of magnitude superior to 93% of the cache lookups)

        10 worst BTree node file read times:

        $ cat btree_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail
        1 406.357
        1 406.386
        1 406.475
        1 406.482
        1 406.508
        1 406.535
        1 409.724
        1 409.826
        1 425.302
        1 425.458

        ==== Small docs (about 1.2Kb each)

        == 209810 cache lookups

        Top 5 frequency

        $ grep 'doc_cache_hit' small_doc_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -5
        126144 0.005
        40580 0.006
        24782 0.004
        8403 0.007
        3027 0.008

        ~91% of cache lookups took less than 0.006ms to complete

        10 worst cache lookup times

        $ grep 'doc_cache_hit' small_doc_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail
        1 21.146
        1 21.645
        1 22.102
        1 22.175
        1 22.453
        1 23.23
        1 26.782
        1 27.912
        1 30.98
        1 43.971

        == 220519 small doc file reads

        Top 5 frequency

        $ grep 'doc_file_read' small_doc_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -5
        2379 0.04
        2207 0.041
        1889 0.042
        1850 0.039
        1363 0.043

        $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.006;' | wc -l
        220519

        All small doc file reads took more than 0.006ms to complete

        $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.1;' | wc -l
        197054

        89% of the small doc file reads took more than 0.1ms to complete (2 orders of magnitude superior to 91% of the cache lookups)

        $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 1.0;' | wc -l
        136710

        62% of the small doc file reads took more than 1.0ms to complete (3 orders of magnitude superior to 91% of the cache lookups)

        $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.5;' | wc -l
        159923

        ~73% of the small doc file reads took more than 0.5ms to complete (2 orders of magnitude superior to 91% of the cache lookups)

        10 worst read times

        $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail
        1 122.645
        1 122.657
        1 122.67
        1 122.672
        1 125.368
        1 125.401
        1 149.895
        1 150.192
        1 150.637
        1 150.948

        ==== Large docs (about 100Kb each)

        == 27670 cache lookups

        Top 10 frequency

        $ grep 'doc_cache_hit' large_doc_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -10
        306 0.12
        304 0.114
        304 0.107
        293 0.115
        292 0.121
        290 0.111
        290 0.108
        289 0.13
        285 0.124
        284 0.136

        $ grep 'doc_cache_hit' large_doc_cache_lookups.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ < 0.20;' | wc -l
        24016

        87% of the cache lookups took less than 0.2ms

        10 worst cache lookup times

        $ grep 'doc_cache_hit' large_doc_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail
        1 19.161
        1 20.373
        1 20.557
        1 21.272
        1 22.963
        1 23.549
        1 24.099
        1 25.099
        1 25.611
        1 27.38

        == 26741 large doc file reads

        Top 10 frequency

        $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -10
        8 5.119
        6 5.545
        6 5.422
        6 4.979
        6 4.812
        6 4.791
        6 4.715
        6 4.701
        6 4.413
        6 4.065

        $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 4.000;' | wc -l
        23029

        86% of the large doc file reads took more than 4.0ms to complete (1 order of magnitude superior to 87% of the cache lookups)

        $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ < 0.2;' | wc -l
        4

        4 out of 26741 large doc file reads took less than 0.2ms to complete

        10 worst read times

        $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail
        1 585.005
        1 585.987
        1 588.969
        1 592.247
        1 592.519
        1 593.615
        1 593.981
        1 594.967
        1 608.922
        1 609.879

        $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 100.0;' | wc -l
        3678

        ~14% of the large doc file reads took more than 100.0ms (3 orders of magnitude superior to 87% of the cache lookups)

        $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 20.0;' | wc -l
        12714

        ~48% of the large doc file reads took more than 20.0ms (2 orders of magnitude superior to 87% of the cache lookups)

        =========

        All these tests were done in a Linux machine (Thinkpad T500), with Erlang OTP R14B and an hard drive of 5400 rpms.

        I would love to see the results in a machine with a SSD drive. Unfortunately I don't have one to test.

        I still have some things to do on that branch (including cache specific test cases).
        But given community approval, I'll quickly move this forward.

        I attach here a tarball with the files I used for this analysis and the logging patch mentioned before, in case anyone wants to double check the results.

        Comments?

        Show
        Filipe Manana added a comment - All the caching efforts are now in a new branch: https://github.com/fdmanana/couchdb/commits/couch_append_cache Basically, I dropped term_cache and created a new cache module couch_cache.erl that is based on term_cache and the existing auth_cache (for faster lookups). Most important, I made a fairly detailed analysis, not relying exclusively in relaximation graphs, which are IMO, hard to interpret sometimes. Over that branch, I applied this patch: http://friendpaste.com/ZZrIsE8FQ7U2HN1XDiBnj This patch adds io:format calls around the cache lookups and file read operations and reports the time spent (in milliseconds) for each of these operations. With that patch applied, I ran several times the readers and writers relaximation test with 50 writers, 200 readers for a duration of 5 minutes: 1 ran for small documents (around 1.2Kb each) with caching enabled 1 ran for small documents (around 1.2Kb each) with caching disabled 1 ran for large documents (around 100Kb each) with caching enabled 1 ran for large documents (around 100Kb each) with caching disabled I then extracted the relevant messages from the logs (I ran CouchDB with ./utils/run | tee log) like this: $ egrep 'btree_cache_' log > 'btree_cache_lookups.txt' $ egrep 'btree_file_read' log > 'btree_file_reads.txt' $ egrep 'doc_cache_' log > 'small_doc_cache_lookups.txt' etc... Now, up to the analysis results: ==== BTree nodes == 859513 cache lookups Top 5 frequency: $ grep 'btree_cache_hit' btree_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -5 441509 0.005 284771 0.004 72980 0.006 13761 0.007 7356 0.008 ~93% of cache lookups took up to 0.006ms 10 worst cache lookup times $ grep 'btree_cache_hit' btree_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail 1 20.69 1 20.828 1 22.12 1 22.408 1 22.668 1 23.361 1 25.732 1 26.346 1 33.791 1 37.375 == 726795 BTree node file reads Top 5 frequency $ cat btree_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -5 3742 0.038 3666 0.037 3564 0.036 3331 0.039 3293 0.044 $ cat btree_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.06;' | wc -l 726795 All BTree node file reads took more than 0.06ms to complete (one order of magnitude superior to 93% of the cache lookups) $ cat btree_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.1;' | wc -l 652910 ~90% of the BTree node file reads take more than 0.1ms (2 orders of magnitude superior to 93% of the cache lookups) $ cat btree_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 1.0;' | wc -l 453728 62% of the BTree node file reads took more than 1.0ms (4 orders of magnitude superior to 93% of the cache lookups) 10 worst BTree node file read times: $ cat btree_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail 1 406.357 1 406.386 1 406.475 1 406.482 1 406.508 1 406.535 1 409.724 1 409.826 1 425.302 1 425.458 ==== Small docs (about 1.2Kb each) == 209810 cache lookups Top 5 frequency $ grep 'doc_cache_hit' small_doc_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -5 126144 0.005 40580 0.006 24782 0.004 8403 0.007 3027 0.008 ~91% of cache lookups took less than 0.006ms to complete 10 worst cache lookup times $ grep 'doc_cache_hit' small_doc_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail 1 21.146 1 21.645 1 22.102 1 22.175 1 22.453 1 23.23 1 26.782 1 27.912 1 30.98 1 43.971 == 220519 small doc file reads Top 5 frequency $ grep 'doc_file_read' small_doc_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -5 2379 0.04 2207 0.041 1889 0.042 1850 0.039 1363 0.043 $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.006;' | wc -l 220519 All small doc file reads took more than 0.006ms to complete $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.1;' | wc -l 197054 89% of the small doc file reads took more than 0.1ms to complete (2 orders of magnitude superior to 91% of the cache lookups) $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 1.0;' | wc -l 136710 62% of the small doc file reads took more than 1.0ms to complete (3 orders of magnitude superior to 91% of the cache lookups) $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 0.5;' | wc -l 159923 ~73% of the small doc file reads took more than 0.5ms to complete (2 orders of magnitude superior to 91% of the cache lookups) 10 worst read times $ cat small_doc_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail 1 122.645 1 122.657 1 122.67 1 122.672 1 125.368 1 125.401 1 149.895 1 150.192 1 150.637 1 150.948 ==== Large docs (about 100Kb each) == 27670 cache lookups Top 10 frequency $ grep 'doc_cache_hit' large_doc_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -10 306 0.12 304 0.114 304 0.107 293 0.115 292 0.121 290 0.111 290 0.108 289 0.13 285 0.124 284 0.136 $ grep 'doc_cache_hit' large_doc_cache_lookups.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ < 0.20;' | wc -l 24016 87% of the cache lookups took less than 0.2ms 10 worst cache lookup times $ grep 'doc_cache_hit' large_doc_cache_lookups.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail 1 19.161 1 20.373 1 20.557 1 21.272 1 22.963 1 23.549 1 24.099 1 25.099 1 25.611 1 27.38 == 26741 large doc file reads Top 10 frequency $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | sort -n -r | head -10 8 5.119 6 5.545 6 5.422 6 4.979 6 4.812 6 4.791 6 4.715 6 4.701 6 4.413 6 4.065 $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 4.000;' | wc -l 23029 86% of the large doc file reads took more than 4.0ms to complete (1 order of magnitude superior to 87% of the cache lookups) $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ < 0.2;' | wc -l 4 4 out of 26741 large doc file reads took less than 0.2ms to complete 10 worst read times $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | sort -n | uniq -c | tail 1 585.005 1 585.987 1 588.969 1 592.247 1 592.519 1 593.615 1 593.981 1 594.967 1 608.922 1 609.879 $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 100.0;' | wc -l 3678 ~14% of the large doc file reads took more than 100.0ms (3 orders of magnitude superior to 87% of the cache lookups) $ grep 'doc_file_read' large_doc_file_reads.txt | cut -d ' ' -f 2 | perl -n -e 'print $_ if $_ > 20.0;' | wc -l 12714 ~48% of the large doc file reads took more than 20.0ms (2 orders of magnitude superior to 87% of the cache lookups) ========= All these tests were done in a Linux machine (Thinkpad T500), with Erlang OTP R14B and an hard drive of 5400 rpms. I would love to see the results in a machine with a SSD drive. Unfortunately I don't have one to test. I still have some things to do on that branch (including cache specific test cases). But given community approval, I'll quickly move this forward. I attach here a tarball with the files I used for this analysis and the logging patch mentioned before, in case anyone wants to double check the results. Comments?
        Hide
        Filipe Manana added a comment -

        Adam,

        Thanks for the review.

        I updated the term_cache_trees module: http://github.com/fdmanana/couchdb/commit/e53d37f65f5984bdcf239315a6394f1e8dbd2adb

        (it is based on an ets implementation, so it might have still more room for optimizations)

        As for the leak after view compaction, I think just the following line solves it: http://github.com/fdmanana/couchdb/commit/4c92720a5b1fb6607a09bef592345fd5d80d40fa

        Show
        Filipe Manana added a comment - Adam, Thanks for the review. I updated the term_cache_trees module: http://github.com/fdmanana/couchdb/commit/e53d37f65f5984bdcf239315a6394f1e8dbd2adb (it is based on an ets implementation, so it might have still more room for optimizations) As for the leak after view compaction, I think just the following line solves it: http://github.com/fdmanana/couchdb/commit/4c92720a5b1fb6607a09bef592345fd5d80d40fa
        Hide
        Adam Kocoloski added a comment -

        Regarding #3: I take it back - I'm wrong about DB compaction. The cache is linked to the transient process that does the compaction, so it disappears automatically. I do still think there's a leak in view group compaction, though its init_group(), not reset_group() which does the work.

        Show
        Adam Kocoloski added a comment - Regarding #3: I take it back - I'm wrong about DB compaction. The cache is linked to the transient process that does the compaction, so it disappears automatically. I do still think there's a leak in view group compaction, though its init_group(), not reset_group() which does the work.
        Hide
        Adam Kocoloski added a comment -

        Hi Filipe, I read through the term_cache_trees code and the patches to couch. I have a couple of comments:

        1) The free_cache_entry code could save one get call by using take_smallest/1 and take_largest/1 instead of smallest/1 and largest/1 on the access time tree, right?

        2) Similarly, I think you could skip the gb_trees:delete(Key, Items) call in the put handler and use gb_trees:enter instead of insert at the end of the handler.

        3) Unless I'm missing something I believe you're leaking a cache process during DB and view group compaction. A new_btree_cache() is created during couch_db_updater:init_db() and couch_view_group:reset_group(), but the old cache is not destroyed when either compaction finishes.

        Cheers, Adam

        Show
        Adam Kocoloski added a comment - Hi Filipe, I read through the term_cache_trees code and the patches to couch. I have a couple of comments: 1) The free_cache_entry code could save one get call by using take_smallest/1 and take_largest/1 instead of smallest/1 and largest/1 on the access time tree, right? 2) Similarly, I think you could skip the gb_trees:delete(Key, Items) call in the put handler and use gb_trees:enter instead of insert at the end of the handler. 3) Unless I'm missing something I believe you're leaking a cache process during DB and view group compaction. A new_btree_cache() is created during couch_db_updater:init_db() and couch_view_group:reset_group(), but the old cache is not destroyed when either compaction finishes. Cheers, Adam
        Hide
        Filipe Manana added a comment -

        For a few (2, 3) DBs opened, with a cache size of 100, it doesn't seem noticeable. Measured by looking at 'top' on Linux.

        Unfortunately relaximation doesn't measure CPU and memory usage (or some other CouchDB perfomance test tool).

        Nevertheless, any of the caches can be enabled or disabled at a DB/View group level or globally. Just wondering if the current defaults are ok.

        Show
        Filipe Manana added a comment - For a few (2, 3) DBs opened, with a cache size of 100, it doesn't seem noticeable. Measured by looking at 'top' on Linux. Unfortunately relaximation doesn't measure CPU and memory usage (or some other CouchDB perfomance test tool). Nevertheless, any of the caches can be enabled or disabled at a DB/View group level or globally. Just wondering if the current defaults are ok.
        Hide
        Paul Joseph Davis added a comment -

        is there a way to look at the difference in CPU in RAM usage due to the different setups. I'm wondering how much of a tradeoff this would be.

        Show
        Paul Joseph Davis added a comment - is there a way to look at the difference in CPU in RAM usage due to the different setups. I'm wondering how much of a tradeoff this would be.
        Hide
        Filipe Manana added a comment -

        I ran a relaximation test, with the default settings (BTree caches with size 100 and no doc cache):

        $ node tests/compare_write_and_read.js --wclients 300 --rclients 150 \
        -name1 btree_caching -name2 trunk \
        -url1 http://localhost:5984/ -url2 http://localhost:5985/ \
        --duration 120

        Results are very significant, an improvement in both reads and writes:

        http://graphs.mikeal.couchone.com/#/graph/6a174582ead9d38a9200967573028e16

        Show
        Filipe Manana added a comment - I ran a relaximation test, with the default settings (BTree caches with size 100 and no doc cache): $ node tests/compare_write_and_read.js --wclients 300 --rclients 150 \ -name1 btree_caching -name2 trunk \ -url1 http://localhost:5984/ -url2 http://localhost:5985/ \ --duration 120 Results are very significant, an improvement in both reads and writes: http://graphs.mikeal.couchone.com/#/graph/6a174582ead9d38a9200967573028e16
        Hide
        Filipe Manana added a comment -

        Updated the branch to use the 2nd (more flexible) configuration.
        Full patch diff at:

        http://github.com/fdmanana/couchdb/compare/btree_node_and_doc_caching

        Show
        Filipe Manana added a comment - Updated the branch to use the 2nd (more flexible) configuration. Full patch diff at: http://github.com/fdmanana/couchdb/compare/btree_node_and_doc_caching
        Hide
        Paul Joseph Davis added a comment -

        I much prefer the second version for both its clarity and extra flexibility.

        Show
        Paul Joseph Davis added a comment - I much prefer the second version for both its clarity and extra flexibility.
        Hide
        Filipe Manana added a comment - - edited

        An alternative scheme for the .ini configuration, would be along the lines:

        [database_btree_cache]
        somedb1 = [

        {size, 50}, {policy, lru}]
        somedb2 = [{size, 200}, {policy, mru}]
        _default = [{size, 100}, {policy, lru}]

        [doc_cache]
        somedb1 = [{size, 10}, {policy, lru}]
        somedb2 = [{size, 100}, {policy, mru}]
        _default = [{size, 0}] ; disabled for all other databases

        [view_group_btree_cache]
        _design/foobar = [{size, 300}, {policy, lru}]

        _design/focus = [{size, 50}

        ,

        {policy, lru}]
        _default = [{size, 100}, {policy, lru}

        ]

        Instead of the scheme in the current patch:

        [couchdb]
        database_btree_cache_size = 100 ; max number of cached BTree nodes per database (set to 0 to disable)
        database_btree_cache_policy = lru ; must be lru or mru
        view_btree_cache_size = 100 ; max number of cached BTree nodes per view group (set to 0 to disable)
        view_btree_cache_policy = lru ; must be lru or mru
        doc_cache_size = 0 ; max number of cached documents per database (set to 0 to disable)

        Show
        Filipe Manana added a comment - - edited An alternative scheme for the .ini configuration, would be along the lines: [database_btree_cache] somedb1 = [ {size, 50}, {policy, lru}] somedb2 = [{size, 200}, {policy, mru}] _default = [{size, 100}, {policy, lru}] [doc_cache] somedb1 = [{size, 10}, {policy, lru}] somedb2 = [{size, 100}, {policy, mru}] _default = [{size, 0}] ; disabled for all other databases [view_group_btree_cache] _design/foobar = [{size, 300}, {policy, lru}] _design/focus = [{size, 50} , {policy, lru}] _default = [{size, 100}, {policy, lru} ] Instead of the scheme in the current patch: [couchdb] database_btree_cache_size = 100 ; max number of cached BTree nodes per database (set to 0 to disable) database_btree_cache_policy = lru ; must be lru or mru view_btree_cache_size = 100 ; max number of cached BTree nodes per view group (set to 0 to disable) view_btree_cache_policy = lru ; must be lru or mru doc_cache_size = 0 ; max number of cached documents per database (set to 0 to disable)

          People

          • Assignee:
            Filipe Manana
            Reporter:
            Filipe Manana
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development