Couchdb 性能测试 之 查询数据

Couchdb：

引用

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.

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，

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

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

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