Couchdb 性能测试 之 查询数据

Couchdb：

[quote]Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. Among other features, it provides robust, incremental replication with bi-directional conflict detection and resolution, and is queryable and indexable using a table-oriented view engine with JavaScript acting as the default view definition language.[/quote]


Couchdb是以Rest方式来完成操作的分布式文档数据库，要多Couchdb完成操作的话，必须通过执行Http请求。传统数据库是通过DBAdapter完成消息传递的，那么可以认为：Http请求的效率和传统的DBAdapter请求的效率，在一定程度上影响着Couchdb和传统数据库的性能。

在Couchdb中，拿插入数据来说，每次插一条数据，客户端必须发起一次put请求，Couchdb再接受这个请求并作处理。下面我就要做这样的一次测试，来比较Couchdb和Mysql两种数据库的插入数据的速度。插mysql和couchdb的操作都从客户端发起，mysql和couchdb同时装在一台server上。通过benchmark记录操作耗时。

测试环境：一台server，一台client，

server：DELL1950划分的一台虚拟机，cpu:2,mem:2GB
mysql：Server version: 5.0.67-0ubuntu6 (Ubuntu)
couchdb：Apache CouchDB 0.8.0-incubating (LogLevel=info)
文件系统：

Filesystem Type Size Used Avail Use% Mounted on
/dev/sda1 ext3 85G 1.5G 80G 2% /
tmpfs tmpfs 1013M 0 1013M 0% /lib/init/rw
varrun tmpfs 1013M 356K 1012M 1% /var/run
varlock tmpfs 1013M 0 1013M 0% /var/lock
udev tmpfs 1013M 2.6M 1010M 1% /dev
tmpfs tmpfs 1013M 0 1013M 0% /dev/shm

client：一台装有LoadRunner的服务器来模拟多个并发请求。

测试场景：
1、服务端：数据库状况为：{"db_name":"couchdbvsmysql","doc_count":1000,"doc_del_count":0,"update_seq":1000,"compact_running":false,"disk_size":2376834}
客户端：通过LoadRunner发送大量请求，并发设置为50，没有时间间隔，再此情况下查看couchdb的响应速度（TPS），并监控couchdb服务器的CPU和Load等其它性能数据。
2、客户端并发设置为500，其它与场景一相同。

场景一测试结果：

TPS：571，CPU：83%（其中SI和HI较高，分别为20%多和10%多），LOAD：2.1，

[quote="top"]top - 21:25:20 up 8 days, 23:21, 3 users, load average: 1.95, 1.63, 1.26
Tasks: 104 total, 1 running, 102 sleeping, 1 stopped, 0 zombie
Cpu(s): 28.6%us, 28.2%sy, 0.0%ni, 12.5%id, 0.0%wa, 7.3%hi, 23.4%si, 0.0%st
Mem: 2072680k total, 831620k used, 1241060k free, 170248k buffers
Swap: 3879656k total, 0k used, 3879656k free, 469088k cached[/quote]

[img]/upload/attachment/71824/e497f80a-b1ba-32f4-bdb8-cd53f9614fd6.jpg[/img]


[img]/upload/attachment/71826/608bd959-62b5-3a09-a457-01836bd870ac.jpg[/img]

为什么软中断和硬中断占用CPU这么高我就不知道了，这种情况很少见，可能是虚拟机的缘故，也可能是ErlangHttp的缘故。

场景二测试结果和场景一相同，可见ErlangHttp对并发请求的支持是比较稳定的，至少500并发以内没有出现波动，TPS不变，并发上升后，响应时间线性上升。