0
回答

实验环境:EC2 的 m2.2xlarge机器(32G内存,4核,高性能的IO,850G磁盘)
第一次测试
采用这个脚本启动服务,然后使用 blitz 的压测服务,使用下面的命令定制测试方法,前30秒将并发从1长到1024,然后维持在1024上30秒。
-r california -p 1-1024:30,1024-1024:30 http://our.couch/
得到的结果如下:
当并发量到1024后,各项参数指标都波动很厉害,错误频发。我们看到图中绿色的响应时间也直线上升。
这个问题是很容易解决的,因为couchdb目前是跑在非特权的couchdb用户下,其打开文件数上限按系统默认的是1024,所以首先修改这个值:
echo "couchdb - nofile 10240" >> /etc/security/limits.conf
然后我们再调整一些网络参数
cat << 'EOF' >> /etc/sysctl.conf net.core.rmem_max = 16777216 net.core.wmem_max = 16777216 net.ipv4.tcp_rmem = 4096 87380 16777216 net.ipv4.tcp_wmem = 4096 65536 16777216 net.ipv4.tcp_mem = 50576 64768 98152 net.ipv4.tcp_no_metrics_save = 1 net.core.netdev_max_backlog = 5000 net.ipv4.tcp_tw_recycle = 1 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_max_syn_backlog = 100000 net.ipv4.tcp_sack = 0 net.core.somaxconn = 65535 net.ipv4.ip_local_port_range = 1024 65535 EOF
同样,再加上对传输缓冲区的大小调整
ifconfig eth0 txqueuelen 10000
第二次测试
这次我们修改测试的参数,将最大并发调整到10k,得出下面的结果:
结果显示,在并发达到2300之前,响应时间基本上是一条直线,而并发超过2300以后,响应时间出现了比较大的波动。虽然响应时间从几毫秒上升到了几秒,但总的来说,达到了C10K的限制。
这个测试中CouchDB并没有进行任何DB操作和View操作,测试结果仅仅是对CouchDB在MochiWeb服务器(Erlang的Web服务器)上的纯性能指标。
作者也指出,实际上此文只是一个简单的优化与测试,实际上期待有更多的优化方案能够出现并分享出来。比如可以将Erlang的malloc/free系统调用换成效率更高的tcmalloc调用,还有在任务调度,处理器数,堆栈大小以及垃圾回收等方面都期望能有更进一步的优化方案。
来源:blog.mudynamics.com ;http://blog.nosqlfan.com/html/2994.html