今天想聊聊性能测试一些基本概念，并发用户数，响应时间及吞吐量相关介绍，以及他们之间的关系，熟练掌握了这些基本概念才能游刃有余的设计出自己想要的性能测试场景 首先是并发用户数，并发用户数是性能测试中最常用的指标之一，它包含了业务层和服务层面的含义。

业务层面的并发用户数，指的是实际使用系统的用户总数，但是，单靠这个指标并不能反映系统实际承载的压力，还要结合用户行为模型才能得到系统实际承载的压力服务器层面的并发用户数，指的是“同时向服务器发送请求的数量”，直接反映了系统实际承载的压力。

为了更好地理解这两层含义之间的区别，我们看一个实例：有一个已经投入运营的企业ERP系统，该企业有5000名员工，就是游戏评测说这个系统有5000个账号 根据系统日志分析，该系统同时最大在线用户数说是2500，从宏观上讲，2500就是这个系统的最大并发用户数。

但是2500这个数据仅仅说明系统峰值时段有2500个用户登陆了系统，而服务器所承受的压力取决于用户登陆后的行为，并不能实际代表系统正在承载的压力 假设在某个时间点该系统有30%的用户在浏览页面（对服务器没有发送任何请求），5%用户在提交订单，15%用户在查询订单，而剩下的30%没有任何操作，那么这2500个“并发用户”中真正对服务器产生压力的只有500（5000*（5%+15%））个用户。

在这个例子中5000是系统的潜在用户数，2500是最大的业务并发用户数，而游戏评测500是某个时间点系统实际并发用户数而这500个用户同时执行的业务操作所触发的服务器端的调用，叫做“服务器并发请求数”。

从这个例子可以看出，在系统运行的某个时间点上，有个指标叫同时向服务器发送的请求数量同时向服务器发送请求的数量就是服务器层面的并发用户数，这个指标取决于并发用户数和用户行为模式，而且用户行为模式占比比较大。

因此获取准确的用户行为模式，是性能测试中很关键的一个环节，目前，获取用户行为模式的方式有两种：对于已经上线的系统来说，根据线上系统日志分析方法获取用户行为，以及峰值并发量等信息：而对于未上线的新系统来说，通常的做法就是参考行业中类似系统的统计信息来建立用户行为模式，并分析。

其游戏评测次是响应时间，主要对后端系统响应进行测试，前端响应时间就是客户端收到服务器返回的数据后渲染页面所消耗的时间后端响应时间主要包括网络传输时间加上服务器处理及返回时间，加上数据服务器处理及返回时间及其他系统的处理及返回时间如文件服务器，缓存服务器等。

最后是吞吐量，吞吐量可以直接反映系统的承载能力，但是吞吐量必须要以时间单位为前提可以表示服务器每秒处理的请求的数量或单位时间服务器处理的请求的数量需要注意的是，虽然吞吐量可以直接反映系统的承载能力，但是在不同并发用户数的场景下，系统的性能指标差别也会比较大。

比如，一个场景中100个并发用户，每个用户每隔1秒发送一个请求，另外一个场景每隔10秒发送一个请游戏评测求显然，这两个场景具体一样的吞吐量，但是这两种场景下的性能拐点肯定不同，这两个场景所占用的系统资源也是不同的。

所以需要实际情况并结合并发用户数和响应时间这两个指标来评估性能再来看看并发用户数，响应时间和吞吐量之间的关系 举个例子，比如你去医院做体检，通常需要先去医院前台登记个人信息并领取体检单，然后根据体检单上面的检查项目完成所有的检查。

假设一共需要5个科室的检查，每个科室有3个候诊室，你发现体检中心有很多人做检查，这时你会先去人数较少的科室进行检查，直到完成5个科室的所有检查，最后离开医院我们把医院体检比作一个软件系统，你进入到体检中心开始检查直到完成所有的检查项目就是响应时间，同时在体检中游戏评测心参加体检的所有人数就是并发用户数，系统的吞吐量就相当于单位时间内完成所有科室体检的人数，相当于服务器单位时间内处理请求的数量。

当你到达医院比较早，体检人数较少，每个科室都基本不用排队，你就以最快的速度完成整个体检相当于并发用户数比较低，响应时间快，因为并发用户数比较低，所以吞吐量也比较低可以得出结论：并发用户数少，响应时间低，系统资源处于空闲状态，把这个阶段叫做空间阶段。

当你到医院体检时，体检人数慢慢增多，体检中心一些科室排队的人数也渐渐增多，部分科室不用排队，排队时间也不会很长，我们可以在较短时间内完成所有体检也就是说，随着并发用户数的增加，系统的吞吐量也会随之增加，我们把这个阶段叫做线性游戏评测增长区间。

当医院体检人数越来越多时，每个科室都需要排队，而且每个科室排队的队伍都很长，你每检查完一个项目都需要等很久才能检查下一个项目，这样一来你完成体检的时间就要变长也就是说，当系统的并发用户数达到一定数量后，每个用户的响应时间会随之变长，系统的吞吐量不会随着并发用户数的增加而增加。

因此把这种状态叫做拐点，即随着并发用户数的增加，响应时间变长，系统处理请求的数量趋于饱和，系统的吞吐量不会随着并发用户数的增加而增加，把这个时间点称作拐点当医院体检人数越来越多，每个科室候诊室都排满了人，候诊室检查完了的人出不来，排队的人又进不去。

也就是说系统的承载能力达到了极限，每个用户的响应时间变得无限长，系游戏评测统的吞吐量也慢慢降低甚至变成0，此时的系统已经被压垮可以得出随着并发用户数的不断增加，系统处理能力达到饱和状态如果继续增加并发用户数，最终用户的响应时间会变得无限长，系统的吞吐量也会慢慢变成0，系统处于被压垮的状态，我们把这种状态称为过度饱和状态。

通过这个类比大致已经清楚了并发用户数，吞吐量和响应时间的关系，只有理解了这些性能测试指标之间的关系，才能在性能测试场景设计中设计出有的放矢的场景对于后端性能测试的负载，我们一般只会把它设计中线性增长区间内。

对于压力测试的负载，我们一般设计在过度饱和区间内再来说说常见的性能测试类型：后端性能测试：大家常说的性能测试，其实指的就是后端性能测试，也就是服务游戏评测器端测试后端性能测试主要是利用工具模拟大量用户并发去请求服务器，然后获取系统性能的各项指标，并且验证各项性能指标是否符合性能需要的预期指标。

这里的指标除了包括并发用户数，响应时间，系统吞吐量，还包括服务器各类资源的使用情况，如CPU占用率，内存使用率，磁盘IO和网络IO，以及JVM内存是否出现溢出，回收是否出现异常等 。

压力测试：就是后端压力测试，一般采用的是性能测试的方法，不断对系统施加压力，验证系统处于临界饱和阶段的稳定性及性能指标，并试图找到系统处于临界状态时影响性能的主要瓶颈压力测试多用于系统容量规划的测试在执行压力测试时还会在临界饱和状态下继续施加压力，直到系统瘫痪，观察这段时间的系游戏评测统运行状态。

然后逐渐减少压力，观察瘫痪的系统能否恢复原状配置测试：主要用于观察系统在不同配置下的性能表现，通常采用后端性能测试方法基于同样的性能基准测试，观察不同配置条件下的系统性能的差异，根本目的是找到特定压力模式下的最佳配置。

并发测试：并发测试指的是同一时间调用后端服务在一段时间内观察被调用服务在并发情况下的性能表现，主要发现资源竞争，资源死锁等问题主要采用性能测试的方法，场景设计上加上集合点，比如设置100个并发用户数，这100个并发用户数同时向服务器发送请求。

可靠性测试或稳定性测试：可靠性测试是验证系统在长时间运行下，通常是N*24H，其本质就是通过长时间模拟真实的系统负载来发现系统是游戏评测否存在内存泄露等问题基本的性能测试类型大致就是这些，大家可以根据公司性能需求制定需要的性能测试类型。

基本的性能测试基础就讲这么多，欢迎大家进行补充及提意见，一起成长吧。