性能测试入门（二）：做个最简单的性能测试

之前在《性能测试中的各项指标告诉我们什么》简单介绍了一些基本的性能指标的含义，明确了我们性能测试的目标是在保证请求成功率及不超过目标请求时间的情况下，找出我们系统的最大并发量。在这篇文章中我们做些实践，以程序员小张的视角来做一次性能测试。

做个最简单的性能测试

首先我们把问题简单化一些，假设小张从业务经理接到的一个网站开发任务，这个网站只设计了一个网页，内容是每天公司都会更新发布的10条信息。

好了，因为我们的假设，任务很简单，小张三下五除二就把功能实现做完了，把程序部署到了一台服务器上，然后告知经理做完了。经理说，这个网站很重要，是董事长她小姨子亲手抓的项目，是公司的脸面，董事长一再强调不能做成12306网站那样一点就挂，你这程序能不能撑得住。小张说那我做下性能测试吧

小张先问了问业务经理，说我们的最大响应时间Latency是多久，业务经理有点蒙逼，说你说啥。小张清清嗓子，就是网站用户敲入网址，等待网页打开，最多能等待几秒？业务经理说，你来定吧，于是小张定了3秒。

定了3秒的最大响应时间，小张在网上找了一个测试工具（后文中我们会说有多少种测试工具），开始性能测试：

第一次测试

启动100个线程，每个线程访问一个页面100次，进行压测，

结果32秒完成1万请求，没有失败，每个请求平均时长32毫秒，请问在这次测试中，QPS是多少，并发量是多少？

QPS：10000个请求/32秒=312.5请求/秒

*并发量：312.5*32=100

第二次测试

启动1000个线程，每个线程访问一个页面100次，进行压测，

结果313秒完成10万请求，没有失败，每个请求平均时长3.1秒，请问在这次测试中，QPS是多少，并发量是多少？

QPS：100000个请求/313秒=319请求/秒

并发量：319*3.1=990

因为第二次测试时平均响应时长已经超过了3秒，小张看了看990这个数字，觉得系统目前最大的并发量应该在1000附近。于是跑去告诉业务经理，网站性能是最高支持1000个并发。业务经理挠了挠头，说可是我们公司内部就有3000人啊，所有人都去看一眼岂不是挂了。小张说你觉得用户刷新过一次会隔多久刷新第二次，业务经理说全部看完网页应该是5秒，就会刷新第二次了。小张说那就是思考时间大概是5秒，思考时间为5秒的情况下，并发1000的意思就是就是支持5000个用户刷新。业务经理点点头，很满意的走了。

这是最为简单的一个性能测试过程的模拟。

要考虑更多

上面的那个例子，只是为了简单体会下性能测试的大概的流程，忽略掉了很多的东西，但是现实工作中接触到的性能测试，我们需要考虑更多：

1、系统的瓶颈

性能测试的一个重要目的就是找出系统的性能瓶颈，找到瓶颈的目的其实是为了优化或者保证能优化的可能性。从软件开发角度来讲，我们对系统瓶颈是有期望的，我们期望瓶颈出现在硬件层面，而不要出现在软件层面。如果在性能测试中你发现服务器的CPU、内存等硬件指标一直都没有什么变化，那就意味着肯定是瓶颈出现在网络带宽和软件上，那我们的工作可能就是需要调整DB连接池、OS操作句柄数等指标，我们的工作就是调整这些好调整的，最后调整那些不好调整的。

从上面两次测试结果来看，虽然第二次每个请求平均时长超过3.1秒，但是其实仔细看下，相较于第一次，系统的QPS并没有增加，说明其实在第一次测试的时候，其实就已经达到了它的瓶颈。现实的情况是，上面两次结果其实都是笔者本机压测百度网站的结果，而瓶颈其实是笔者机器的出口带宽。当然在真实工作中这是不允许发生的，性能测试的客户机到被测试机间往往要忽略网络要素，通常的做法是把他们放在统一的内网环境。

所以，在实际的测试过程中，不会像小张一样只关心了测试客户端的数据，必须时刻监测服务器及中间件的各项性能指标，以找出系统瓶颈并分析优化以保证瓶颈出现在我们期望他出现的位置。

2、压测的粒度

小张面临的其实是最简单的一种压力测试，单机单应用测试，也就是只有一个主机，只有一个应用，性能非常好估算。但是实际生产环境中往往是多主机多应用的环境，还有就是存在大量的链条式的调用关系，比如必须先调用下单服务后再调用支付服务。这种情况下就需要从单机单应用出发，逐渐扩展到集群的测试，针对链条式的调用关系也要从单应用的测试，变为链路的测试，比如先单独测试下单服务和支付服务，找到他们的最大并发数后，再构建两个都测试的场景，测试链条的最大并发数。不同的软件类型往往有不同的压测方案，各家公司不太一样，没有放之四海皆准的标准。

3、压测数据流量

当压测的粒度定下来，真正进行压测的时候，实际往往要进行模拟真实的数据流量。比如说要真的模拟用户登录（压测环境往往要针对压测改些代码），模拟用户下单，这部分往往是压测工作中工作量最大的部分，因为要准备虚拟的用户数据，撰写压测脚本，还往往要针对压测要修改下目标系统的代码以保证压测可以正常进行（比如跳过密码登录，关闭IP验证等）。在传统软件领域，往往找一台或者几台性能还不错的测试机，执行下测试脚本，往往也就能构建出相对应的流量。即使对用户数据有要求，上万条用户数据模拟也基本够用了。但是对于互联网领域的大型网站来说，压测流量数据的获取往往是个大问题，没有那么多流量数据咋办。通常的做法就是两种：

• 线上流量回放：通过tcpcopy或者tcpdump把真实用户的数据存下来，然后回放到压力测试环境以获得压力
• 自己研发压测平台：自己开发流量平台，支持构建流量模型，造虚拟流量，撰写压测脚本，把压测脚本放到几百台施压机器上执行，对压力测试环境进行施压。其实跟传统软件找机器模拟是一个意思，但是规模要大得多，所以要求自动化程度高。目前阿里PTS平台其实就是将阿里内部的这种压测能力输出到阿里云上供中小企业能够使用

4、前端性能

仅仅针对WEB页面测试的话，小张的测试中其实还忽略了一个要素，前端。一个网页的访问往往不是单纯的一个请求，而是一组请求，除了html的请求还有接口请求，静态资源请求等。如果要考虑性能损耗的话小张应该把所有请求都考虑在内对服务器进行压测才对。笔者现实生活中就见到过项目因为前端请求图片过多大量占用带宽导致整个网站无法访问的情况发生。当然如果在实际项目上已经做了动静分离，可以单独针对前端资源获取进行服务压力测试。但是前端性能测试还要考量的是，用户体验的方面，比如首屏加载时间等，这个属于前端的领域了，与服务器关系不大，笔者不赘述，可以点此链接了解

前端性能优化和测试工具总结