unixbench服务器性能测试详解
unixbench 是一个用于測试 unix 系统性能的工具。也是一个比較通用的 benchmark， 此測试的目的是对类Unix 系统提供一个主要的性能指示，非常多測试用于系统性能的不同方面，这些測试的结果是一个指数值（index value，如520），这个值是測试系统的測试结果与一个基线系统測试结果比較得到的指数值，这样比原始值更easy得到參考价值，測试集合里面全部的測试得到的指数值结合起来得到整个系统的指数值。源于1995 年，基线系统是“George”。一个工作站：SPARCstation 20‐61，128MB RAM，Solaris2.3。此系统的指数值被设定为10，所以。假设一个系统的最后结果分数为520。意思是指此系统比基线系统执行快52 倍。
一 安装
Unixbench-5.1.2.tar.gz下载地址：http://soft.vpser.net/test/unixbench/
tar -xzvf unixbench-5.1.2.tar.gz
cd Unixbench-5.1.2
阅读README文件，得知假设不须要进行图形測试或者不在图形化界面下測试，则将Makefile文件里GRAPHICS_TEST = defined凝视掉。我的是在46行。
make
二 使用
执行./Run
对于执行结果。说明例如以下：
測试项目
项目说明
基准线
Dhrystone 2 using register variables
測试 string handling
116700.0lps
Double-Precision Whetstone
測试浮点数操作的速度和效率
55.0MWIPS
Execl Throughput
此測试考察每秒钟能够执行的 execl 系统调用的次数
43.0lps
File Copy 1024 bufsize 2000 maxblocks
測试从一个文件向另外一个文件数据传输的速率。
3960.0KBps
File Copy 256 bufsize 500 maxblocks
測试从一个文件向另外一个文件数据传输的速率。
1655.0KBps
File Read 4096 bufsize 8000 maxblocks
測试从一个文件向另外一个文件数据传输的速率。
5800.0KBps
Pipe-based Context Switching
測试两个进程（每秒钟）通过一个管道交换一个不断增长的整数的次数。
12440.0lps
Pipe Throughput
一秒钟内一个进程能够向一个管道写 512 字节数据然后再读回的次数
4000.0lps
Process Creation
測试每秒钟一个进程能够创建子进程然后收回子进程的次数（子进程一定马上退出）。
126.0lps
Shell Scripts (8 concurrent)
測试一秒钟内一个进程能够并发地開始一个shell 脚本的 n 个拷贝的次数，n 一般取值1，2，4，8.
42.4lpm
System Call Overhead
測试进入和离开操作系统内核的代价，即一次系统调用的代价。
6.0lpm
Score
很多用户都用UnixBench做性能测试，并做厂商之间的对比，那UnixBench到底做了哪些性能测试，本篇从代码层面阐述UnixBench做了哪些测试。
在细说UnixBench的实现之前，先放一个总结果UnixBench算分介绍（https://yq.aliyun.com/articles/674729）有类似结果，然后一个个解释。 从结果可以看出，结果分为两块，一块为单进程，一块为多进程，多进程数目默认取决于CPU数目，多进程的测试仅仅是增加了进程数目，内存其实跟单进程一模一样，所以下面的描述都是针对单进程的。
Dhrystone 2 using register variables
这里有比较详细的dhrystone介绍（https://baike.baidu.com/item/Dhrystone/6279514?fr=aladdin），这个主要是测整数性能，对应的浮点数测试是：Double-Precision Whetstone。
恕我眼拙，那一坨运算实在不知所云，于是上网搜了一堆文章,大意是可以通过编译优化提高性能，不能真实反映CPU性能。这篇文章比较有典型意义：Benchmarking in context: Dhrystone。
那绕开里面一坨计算，说下输出：默认就是在10秒内，那一坨计算能计算次数，算出分数后，参考前面篇UnixBench算分介绍，算出Index分数。
Double-Precision Whetstone
既然有整数运算的CPU性能，那么浮点数运算性能也希望有，于是就有了：whets.c 它的代码质量就高多了，我终于读懂了。
它需要得到一个合适的参数. 怎么得出这个运算呢：有坨运算，随着传入参数(xtra)变大，耗时会逐渐增减，当耗时增加到超过2秒时，参数停止变大。
如果跑10秒大概的参数会是怎样呢：625*10/1.238352=5047
根据输入参数，去计算结果，之前一直没有说，那一坨计算是什么，总共分为8步，英文解释还是比较清楚的，采纳了其中的浮点数分数，不过它的时间怎么把其他计算的时间也算在里面了，既然只关心浮点数运算，为什么还要加入N3，N4，N5，N7，N8这几步，后续计算参考前面算法规则UnixBench算分介绍。
Execl Throughput
除了前面介绍的那两个比较复杂，UnixBench其他的运算都比较简单，Execl它的实际就是递归调用，它主要利用的是execl函数。本身execl.c编译出来后的执行文件是execl的二进制文件，execl函数执行的时候记录参数：开始时间，执行次数，耗时（一般都是10秒）。当本次总执行时间耗时超过10秒时，输出执行次数，然后根据算分规则算分，这个思想还是很巧妙的。
File Copy
这个主要是测试的write和read两个函数，测试30秒。实现很简单,先写入一个文件2秒（循环写入），再读2秒，然后从刚刚写入的文件读取数据，写入到另一个文件，循环写入，在30秒的读写次数。 不同的参数测试测的是不同块大小，不同块数的性能，如果测试磁盘建议用FIO测试。
Pipe Throughput
打开一个管道，往管道写入512个bytes，再读出来，测试10秒，总共读写次数
Pipe-based Context Switching
打开两个管道，开启两个进程，其中一个进程往管道1写，往管道2读，另一个进程往管道2写，往管道2读，一个进程完成一次读写，计数+1。其中一个很有意思的事情：如果这两个进程在同一个CPU和不同的CPU有完全不同的性能，在同一个CPU下性能会好很多。这里有篇很细致的分析，值得大家评阅：Unixbench 测试套件缺陷深度分析
Process Creation
就是不停调用fork函数，创建进程，并立马退出，成功一次计数+1。
Shell Scripts
通过fork函数，创建进程，不停地执行一个脚本, 执行成功一次+1. 所谓Shell Scripts (1 concurrent) 一个并发是指传递给脚本：pgms/multi.sh 参数是1，同样Shell Scripts (8 concurrent) ，传递给脚本的参数是8，同时8个子任务并发执行。
System Call Overhead
本意是想计算进入离开操作系统的开销，进入离开一次计数+1，在10秒内的执行次数. 实际执行的效果是fork子进程，waitpid函数后退出，计数+1