实验环境：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