压测Cubieboard
想测一测Cubieboard最多能支撑多少tcp长链接（当然，是比较空闲的链接）。
我的cubieboard上安装的是linaro（其实就是linux），首先得调节单个进程打开的句柄数（修改/etc/security/limit.conf），然后还要修改sysctl里tcp_mem等网络参数（具体配置可以参考这里 1, 2） 然写了一套简单的TCP链接客户端和服务端的代码。Server端用epoll模型; Client端创建500个链接然后把fd放入数组里，每个connection每5秒发送128字节。
开始测试时，在cubieboar上我分别对5个端口启动了5个Server，客户端（我的笔记本）则是用脚本不停的创建Client实例。
测试结果：cubieboard可以支撑到10万个tcp长链接，网络流量稳定保持在3.75MB/s，此时系统内存还有大约300MB free（总共1G），CPU idle在20%左右
cubieboard只有网口没有网卡（也就是没有network controller），所有的收包解包都由CPU完成，所以能支持的流量比较有限，不过撑个10万的闲链接还是没问题的。
还想了解一下cubieboard对https的支撑能力，于是我又在cubieboard上装了tengine（在arm上编译还挺顺利，连warning都没有，编译时间4分钟24秒），配上https签名（参加这里）再用ab压力测试，ab压测脚本是：
ab -n 20000 -c 20 -k url
测试结果：访问https的QPS为755, 访问http的QPS为1269
看来用cubieboard搭个小网站是绰绰有余了，一个小的聊天服务器兴许也可以。
====== 2013.1.28 ======
应 @pythonee 同学的要求，测试了200个并发：
ab -n 20000 -c 200 -k url
测试结果：访问https的QPS为858，访问http的QPS为1741，毕竟是单核，提升不明显，压测的时候CPU idle已经为0了
我另外还试了一下把openssl的签名长度改为512bit，以减轻CPU的压力，再测https，QPS可以到959，当然，签名长度再短，QPS也不可能高于http的1741了
相关文章
- Cubieboard试用手记 - 12 02, 2012
- linux在多核处理器上的负载均衡原理（幻灯片） - 10 22, 2010
- [kernel] 内核缓冲的锁 - 08 11, 2010
Orz...
能否顺便测一测
ab -n 20000 -c 200 -k url
请教一下这类arm board上怎么得到是否存在network controller？
@ex 测试网络收发小包的时候，还不到10MBytes/s，CPU就100%利用率了，（同样的VIA的低功耗机器，也是1G主频，网络到100MBytes/s了CPU利用率还不到10%，它是带有网卡的），故而得出此结论。 cubieboard才400元不到的售价，带CPU、GPU、VPU等等，要是再带network controller，那就很难控制在400元以下了吧
原来如此。pc上可以用lspci之类看到，但这类板子上通常不是pci总线……不知道这些板子(rpi/cubieboard)的总线彼此是否通用呢。
对于此类的网络测试作者有什么提议吗？即要提高此soc的网络能力楼主有什么好的建议
对于提高此开发板网络性能，楼主有什么好建议吗？
@shuge 我也没有好的建议，要么买更好的板子，要么应用就别收发这么多网络包，硬件决定软件。
你好，我想知道客户端是如何实现稳定发出10万个tcp长链接的呢？
普通机器来说，把65535个local port耗尽了不就是无法connect了吗
@Gao，假设server端只listen了80这一个端口，那client端最多只能创建65535个链接链上server;但是我是在server端listen了4个端口，client端分别连接server端的这4个端口，就能到10万了