之前写过不少跟网络相关的 benchmark，比如:
* 《网络质量评估》
* 《10G(82599EB) 网卡测试优化(总)》

上面的更多的是放在带宽使用率上，即如何尽可能的打满，但是都遗漏一个重要的细节，那就是 packet/s，这个论坛的作者一语中的:
– how many packets/sec you have. In fact, network throughput mostly depends on packets/sec, not bytes/sec

可能对于大部分的应用来说，根本无需关注每秒钟到达的包的数量甚至大小，但是对于某些应用来说，这些指标是至关重要的。

要对包(大小、数量、时间)方面的指标做 benchmark，iperf, netperf 之类的就没法用了，他们只能测试带宽，经过一天的使用比较发现下面的一些工具能基本满足需求。要快速的上手的话还是需要对 tcp/ip 有比较深入的了解，比如 ip header，tcp header 之类的，再比如最小的 frame 应该是 64B，这也是众多网络设备厂商做包转发测试的基础，不明白的看下面两张(1, 2)图就清楚了。

跟网络厂商一样，我们也重点关注小包(0-75)的性能，至于小包如何定义，没有严格的标注，我上面的 0-75 也仅仅是从 iptraf 拿到的一个范围，最终还是要根据业务来定。
一般而言，frame(fps) 是针对 data-link(Ethernet) 而言，packet(pps) 是针对 IP 层而言，segment 是针对 TCP 层而言。

nping
基本的功能还是不错的，但是发包能力相对弱了些，试了几种方式，比如下面这个根本达不到 500K/s 的要求，实际也就 150K/s 左右，记得加上 -N/-H，这样速度能提高几个数量级别:
# nping –tcp 192.168.50.52 –rate 500000 -c 500000000 -N -H

三个使用方式:
1. cheatsheet 
2. ARP 的 MIT 还是很方便的 
3. 常用方法

hping3
基本功能跟 nping 类似，tcp, udp, icmp, arp 都可以伪造篡改，但是发包的效率比上面好的多。
我发送 60B 的小包(40B head + 20B data)，–fast/–faster/–flood 三种不同的类型分别能达到 20 rxpck/s, ~130K rxpck/s, 260K rxpck/s，并且在 –flood 状态，tcp, interrupts 基本饱和:
# hping3 -c 100000000 -d 20 -S -p 80 –fast/–faster/–flood  192.168.50.52 –rand-source

使用:
1. cheatsheet 
2. dos using hping3 with spoofed ip in kali linux

pktgen
直接 modpore 往 /proc/net/pktgen/ 里面填 tcp/ip 的选项就好了，操作蛮简单的，可以看下面几篇文档:
* 《pktgen linuxfoundation》
* 《pktgen》
* 《How do I stress test my local network using pktgen?》  
总的来说，这个工具不管是带宽还是发包速率都不是很好控制，一旦启动就直接打满。

packETH 
这是目前用的最满意的一个，分为 gui、cli 两种，cli 的功能不全面，gui 的可以根据带宽、包的大小来做 benchmark。测试服务器通过 X11 forwarding 就可以打开界面了。

关于 GUI 的使用方法，可以看这里:
* http://packeth.sourceforge.net/packeth/GUI_version.html
* http://www.kuncar.net/blog/packeth-tutorial-part-i-the-inetrface-and-the-packet-builder/2013/
* http://www.kuncar.net/blog/packeth-tutorial-part-ii-the-gen-bgen-s-and-pcap-options/2013/

这里我做了一个快速的分别是针对 60B, 150B, 1400B 的包，随机 src MAC、src IP，在尽可能利用带宽的情况下的 benchmark。这个 gist 记录的是 rx_discard 每秒的丢包结果。
用到的工具，观察的现象也很朴素，如下:
while true; do  echo "—- $(date +'%H:%M:%S')" ;R1=$(ethtool  -S em1 | grep rx_dis | cut -d":" -f 2) ;sleep 1;R2=$(ethtool  -S em1 | grep rx_dis| cut -d ":" -f 2); R=`expr $R2 – $R1`; echo $R  ; done;
上面这个是计算每秒 drop 的数量，下面这些是一些不同层面的监控对比:
* sar -n DEV 1 | grep bond0
* iptraf
* ibmonitor
* mpstat -P ALL 1

简要说下结果。小包对系统资源的消耗是非常明显的，这也是无数的公司都花了大量的时间在提升小包处理的效率上。
对于 60B 的小包，系统只能打到 300M，600Kpps/s，rx_discards/s 非常大。
150B 的包，能打到 700M，600Kpps/s，rx_discard/s 同样严重。
1400B 的包，能打到 1800M(两条千兆 bonding)，pps 下降到了 200K，rx_discard 要好的多。
600B  以上的包的情况大为好转，基本都能打到 1800M，同时 rx_discards 明显小很多。

这里有使用 packETH 做的 40G benchmark。

Ostinato
跟 packETH 类似，对于各种协议的包的组合非常灵活，可以生成很多非标准的包，比如 IP over IP, ARP over TCP 等等，文档写的很清楚，上手很快。比较麻烦的是是需要在被 benchmark 的机器部署同样的包，跟 iometer 有点类似，而 packETH 则是 standalone 的。

再介绍两个工具，一个叫 scapy；一个叫 netsniff-ng(1, 2) ，后者有集大成的架势，这里是他的使用文档，因为太全面了，是一个综合性的工具，反而没有专心把一件事做好的工具更精致。

上面的工具还不够胃口？看这里(1, 2)。依然不满意？直接上专业硬件线速发包工具吧，1G、10G、40G 已经没意思了，直接上 400G 的吧。

软件性能测试的基本概念和计算公式

一、软件性能的关注点

对一个软件做性能测试时需要关注那些性能呢？

我们想想在软件设计、部署、使用、维护中一共有哪些角色的参与，然后再考虑这些角色各自关注的性能点是什么，作为一个软件性能测试工程师，我们又该关注什么？

首先，开发软件的目的是为了让用户使用，我们先站在用户的角度分析一下，用户需要关注哪些性能。

对于用户来说，当点击一个按钮、链接或发出一条指令开始，到系统把结果已用户感知的形式展现出来为止，这个过程所消耗的时间是用户对这个软件性能的直观印象。也就是我们所说的响应时间，当相应时间较小时，用户体验是很好的，当然用户体验的响应时间包括个人主观因素和客观响应时间，在设计软件时，我们就需要考虑到如何更好地结合这两部分达到用户最佳的体验。如：用户在大数据量查询时，我们可以将先提取出来的数据展示给用户，在用户看的过程中继续进行数据检索，这时用户并不知道我们后台在做什么。

用户关注的是用户操作的相应时间。

其次，我们站在管理员的角度考虑需要关注的性能点。

1、 相应时间
2、 服务器资源使用情况是否合理
3、 应用服务器和数据库资源使用是否合理
4、 系统能否实现扩展
5、 系统最多支持多少用户访问、系统最大业务处理量是多少
6、 系统性能可能存在的瓶颈在哪里
7、 更换那些设备可以提高性能
8、 系统能否支持7×24小时的业务访问

再次，站在开发（设计）人员角度去考虑。

1、 架构设计是否合理
2、 数据库设计是否合理
3、 代码是否存在性能方面的问题
4、 系统中是否有不合理的内存使用方式
5、 系统中是否存在不合理的线程同步方式
6、 系统中是否存在不合理的资源竞争

那么站在性能测试工程师的角度，我们要关注什么呢？

一句话，我们要关注以上所有的性能点。

二、软件性能的几个主要术语

1、响应时间：对请求作出响应所需要的时间

网络传输时间：N1+N2+N3+N4

应用服务器处理时间：A1+A3

数据库服务器处理时间：A2

响应时间=N1+N2+N3+N4+A1+A3+A2

2、并发用户数的计算公式

系统用户数：系统额定的用户数量，如一个OA系统，可能使用该系统的用户总数是5000个，那么这个数量，就是系统用户数。

同时在线用户数：在一定的时间范围内，最大的同时在线用户数量。
同时在线用户数=每秒请求数RPS（吞吐量）+并发连接数+平均用户思考时间

平均并发用户数的计算：C=nL / T

其中C是平均的并发用户数，n是平均每天访问用户数（login session），L是一天内用户从登录到退出的平均时间（login session的平均时间），T是考察时间长度（一天内多长时间有用户使用系统）

并发用户数峰值计算：C^约等于C + 3*根号C

其中C^是并发用户峰值，C是平均并发用户数，该公式遵循泊松分布理论。

3、吞吐量的计算公式

指单位时间内系统处理用户的请求数

从业务角度看，吞吐量可以用：请求数/秒、页面数/秒、人数/天或处理业务数/小时等单位来衡量

从网络角度看，吞吐量可以用：字节/秒来衡量

对于交互式应用来说，吞吐量指标反映的是服务器承受的压力，他能够说明系统的负载能力

以不同方式表达的吞吐量可以说明不同层次的问题，例如，以字节数/秒方式可以表示数要受网络基础设施、服务器架构、应用服务器制约等方面的瓶颈；已请求数/秒的方式表示主要是受应用服务器和应用代码的制约体现出的瓶颈。

当没有遇到性能瓶颈的时候，吞吐量与虚拟用户数之间存在一定的联系，可以采用以下公式计算：F=VU * R /

其中F为吞吐量，VU表示虚拟用户个数，R表示每个虚拟用户发出的请求数，T表示性能测试所用的时间

4、性能计数器

是描述服务器或操作系统性能的一些数据指标，如使用内存数、进程时间，在性能测试中发挥着“监控和分析”的作用，尤其是在分析统统可扩展性、进行新能瓶颈定位时有着非常关键的作用。

资源利用率：指系统各种资源的使用情况，如cpu占用率为68%，内存占用率为55%，一般使用“资源实际使用/总的资源可用量”形成资源利用率。

5、思考时间的计算公式

Think Time，从业务角度来看，这个时间指用户进行操作时每个请求之间的时间间隔，而在做新能测试时，为了模拟这样的时间间隔，引入了思考时间这个概念，来更加真实的模拟用户的操作。

在吞吐量这个公式中F=VU * R / T说明吞吐量F是VU数量、每个用户发出的请求数R和时间T的函数，而其中的R又可以用时间T和用户思考时间TS来计算：R = T / TS

下面给出一个计算思考时间的一般步骤：

A、首先计算出系统的并发用户数

C=nL / T F=R×C

B、统计出系统平均的吞吐量

F=VU * R / T R×C = VU * R / T

C、统计出平均每个用户发出的请求数量

R=u*C*T/VU

D、根据公式计算出思考时间

TS=T/R