【UP Board】不循规蹈矩，另类UP Board测试

tjcfeng

相关阅读：    https://jingyan.eeboard.com/category/57
好吧，标题的名字可能起的比测试更另类，有标题党的嫌疑。不过呢，各种性能测试呀、跑分呀什么的太普遍了，也就没什么意思了。我的初衷就是想搞搞比较特别的，而且是和工作有些关系的来做个比较，所以最后决定测试一下UP Board能够支持的TCP长连接的最大数量。
   
    大家都知道UP Board采用的是Intel Z8350的CPU，最大只支持2G的内存，经过各大厂商改造后，通过减半带宽增加容量的方法强塞到4G的内存。虽然速度上有所损失，但是好歹内存扩大了一倍，这样就能同时运行更多的程序，尤其是接收大量TCP连接的这种对内存敏感的程序，也就使得这个测试有点用处，从另一个方面说明这个改造是否是成功的。
    由于是在家里用个人电脑测试的，和公司大量的电脑数量比不了，所以只能开虚拟机来模拟客户端发起连接。我的电脑配置是I7 3770和12G内存，其中1个G用做了内存盘，只剩下11个G可以使用，能开几个虚拟机就开几个吧。
   
    下面开始准备测试工具。
    1.从网上随便找的一个TCP压力测试工具，可以发起任意数量的TCP请求（受操作系统限制）；
    2.用go语言写的一个最简单的TCP Server，echo和记录显示Client的数量，其他不做任何功能，只为测试使用。
   
    工具不用说了，TCP Server的代码如下：
package main
import (
"bufio"
"fmt"
"net"
"os"
"./Server"
)
var serverTCP *Server.ServerTCP
func ServerOnReceived(Data []uint8, Len int, Client net.Conn) {
Client.Write(Data)
}
func main() {
serverTCP = new(Server.ServerTCP)
serverTCP.OnReceived = ServerOnReceived
serverTCP.Listen("8080")
reader := bufio.NewReader(os.Stdin)
for {
key, _, _ := reader.ReadLine()
switch string(key) {
case "tcp":
fmt.Println("Clients Count:", len(serverTCP.DeviceList))
case "exit":
return
default:
continue
}
}
}
   
    go语言天生自带协程属性光环，处理大量的TCP请求易如反掌，特别适合于服务器后台程序，测试的首选。
    本地编译运行略过不讲，为了方便查看，找了个小屏幕给UP Board接上，不用来回切换显示器的信号。
   

     TCP Server程序运行，表底内存为0.9G，最大3.4G，那么可用的内存就是2.5G左右，就看看这些内存能够容纳多少个连接吧。

     我的电脑，也就是模拟客户端的机器。大约估计了一下，开了5个虚拟机运行测试程序，再加上主机运行的一个。懒得改电脑的最大连接数，就用系统默认的吧，每个程序发起16000个连接，总共96000个TCP，接近10万，应该够了。
   
测试开始：

    首先启动了主机的测试程序，1万6千个连接完成。

    UP Board毫无压力，内存也从0.9涨到1.2，用了300M左右。
   
第二个程序启动：

    虚拟机上的程序开始运行，很快完成第二个16000。

    UP Board那边32000易如反掌，内存变为1.4G，用了200多M。
   
第三个程序运行：

    正常连接，没有问题，第三个16000。

    UP Board此时48000，内存1.7G，又是300多M。
   
虚拟机上的第四个程序：

    又是16000，没有报错。

    64000个连接了，看来还很轻松，不过内存达到2.0G，已经占用1个G了。
   
继续虚拟机程序：

    已经是第五个程序了，还能连上。

    UP Board显示80000个连接，一个不少，内存又多了200多。
   
最后一个虚拟机程序：

    电脑屏幕有点显示不开了，不过连接照样进行。

    全部运行完成，9万6千个连接，接近10万了，内存又多了300，看来还有富余。
   
不甘心呀，还是没到上限，再增加个虚拟机试试。但是虚拟机的连接复制要把主虚拟机停掉，所以只能先断开16000个连接了。

    再次复制了个虚拟机出来之后，重新运行主虚拟机和新虚拟机，然后再发起32000个连接。

    十一万两千个连接达成，UP Board依然健壮。而且内存2.6G，离全部用满还有不少。
   
    由于我的电脑主机内存已耗尽，无法再开启更多的虚拟机，测试到这里结束。最后的成果，UP Board在正确的保持了112000个TCP长连接且正常通讯没有丢包的情况下，内存依然还有800M左右。据此推算，这个小小的Windows开发板持续容纳十五万个连接应该是可以实现的。CPU的占用率一直很低，只在接收客户端发起的连接和发送数据的时候才会提高频率来计算。虽然我把客户端发送的时间调整为1分钟一次发送，没有那么频繁，但是考虑到Atom这样低端的CPU也能从容应对，并且这次的测试主要是针对连接数而不是处理性能，所以这个开发板可玩性还是很高的。如果换成UP2，自己再加个SSD，也许就真的能当作一台服务器来使用了。
   
（完）