couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Filipe Manana (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-976) Improve database read and write performance using 2 couch_files
Date Sun, 05 Dec 2010 11:02:10 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12966927#action_12966927
] 

Filipe Manana commented on COUCHDB-976:
---------------------------------------

No significant gains?

For small docs:
- for writes I see in average response times reduced by 100 to 200ms;
- for reads I see in average response times reduced by 100ms.

For large docs:
- writes get in average the response time reduced by 1s to 1.5s;
- idem for reads

And the cache patch forget it, I don't think it's worth it, perhaps only for large docs (100kb),
however it doesn't boost performance as much as this patch. Its gains are generally smaller
than 5ms, which is almost insignificant, not to mention the additional complexity it brings:
more code, more gen_servers, 1 ets per cache, etc.
I have an analysis of the caching at https://issues.apache.org/jira/browse/COUCHDB-913

> Improve database read and write performance using 2 couch_files
> ---------------------------------------------------------------
>
>                 Key: COUCHDB-976
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-976
>             Project: CouchDB
>          Issue Type: Improvement
>            Reporter: Filipe Manana
>            Assignee: Filipe Manana
>
> Right now we use a single couch_file server for both updating a database and reading
from a database.
> This is a contention point, as concurrent read/write access to a database implies having
processes waiting for access to the couch_file server.
> The following patches add a couch_file server that is used only by the DB updater process
and another couch_file meant to be used by anyone else only for read operations:
> https://github.com/fdmanana/couchdb/compare/updater_dedicated_fd
> Some performance measurements:
> # updater_fd vs trunk  (small docs, 1Kb each)
> $ node tests/compare_write_and_read.js --wclients 50 --rclients 200 \
>   -name1 updater_fd_small_docs -name2 trunk \
>   -url1 http://localhost:5984/ -url2 http://localhost:5985/ \
>   --duration 300
> http://graphs.mikeal.couchone.com/#/graph/5c859b3e7d1b9bd0488cfe271104a616
> # updater_fd vs trunk  (large docs, 100Kb each)
> $ node tests/compare_write_and_read.js --wclients 50 --rclients 200 \
>   -name1 updater_fd_large_docs -name2 trunk \
>   -url1 http://localhost:5984/ -url2 http://localhost:5985/ \
>   --duration 300 --doc large
> http://graphs.mikeal.couchone.com/#/graph/5c859b3e7d1b9bd0488cfe271104a7a7
> We can see that both the response time and throughput gets significantly better for both
read and writes.
> If no objections I'll commit it to trunk.

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


Mime
View raw message