Couchdb:
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,
为什么软中断和硬中断占用CPU这么高我就不知道了,这种情况很少见,可能是虚拟机的缘故,也可能是ErlangHttp的缘故。
场景二测试结果和场景一相同,可见ErlangHttp对并发请求的支持是比较稳定的,至少500并发以内没有出现波动,TPS不变,并发上升后,响应时间线性上升。
引用
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
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
![](http://writeblog.csdn.net/upload/attachment/71824/e497f80a-b1ba-32f4-bdb8-cd53f9614fd6.jpg)
![](http://writeblog.csdn.net/upload/attachment/71826/608bd959-62b5-3a09-a457-01836bd870ac.jpg)
为什么软中断和硬中断占用CPU这么高我就不知道了,这种情况很少见,可能是虚拟机的缘故,也可能是ErlangHttp的缘故。
场景二测试结果和场景一相同,可见ErlangHttp对并发请求的支持是比较稳定的,至少500并发以内没有出现波动,TPS不变,并发上升后,响应时间线性上升。