关于性能测试中“并发”的解释！|163

关于性能测试中“并发”的解释当我们在谈论“并发”时动辄要求系统支持成百上千并发的性能需求太多了，也许系统在实际中确实存在这样的需求，但能够较全面理解当我们在谈论“并发”时

动辄要求系统支持成百上千并发的性能需求太多了，也许系统在实际中确实存在这样的需求，但能够较全面理解此需求的情况并不多。

对于并发，我过去接触了几种理解，在接触的第一种理解中，“并发”是由中获取，即脚本中所有或部分执行至集合点函数时进行停留，等待触发条件发生以后，同时执行集合点函数后的请求操作的这一个过程，为“并发”（这一个请求操作一般存在多个请求），可惜这种“并发”是无法直接用于衡量系统性能的。而在接触的第二种理解中，“并发”的理解是相对于服务器某一个时间区间内接收的请求数，也就是每秒的点击率（考虑到这点，也就是里面的），为“并发”，这种“并发”是可以用于对系统性能状况进行量化的，但是这种测试思想只是比较片面的从性能指标的角度去衡量系统性能，不能体现出系统性能带给用户何种性能体验（这也是不少开源性能测试工具的问题）。

前一种“并发”的理解普遍获得了初级用户的认可，后一种“并发”的理解普遍获得系统运维、开发人员的认可，在沟通中为了方便区别开来，在两种角色里面，当大家意识到并发的理解存在差异时，大家把前一种被称为“狭义上的并发”，而后一种被称为“广义上的并发”。后来，又从淘宝团队里面了解了一种定义，貌似淘宝把“并发”定义为一个完整的事务请求数量过程（也考虑到这点，也就是里面的）。一直以来，还有一种技术范围以外对“并发”的粗略的理解被第三方测试拿来用了，那就是用户在线数中的某个百分比即并发数。

如果一个团队里面对“并发”的理解有这么多种，那么当我们在讨论性能需求的“支持并发数”时，我们究竟在讨论什么呢？

个人认为，有一部分的原因是由于是惠普（软件即服务的解决方案）的一部分，所以并不是一个纯粹技术人员使用的测试工具，它同时也是一个业务人员可以相对轻易掌握的性能测试工具，因此内很多名词解释也不能单纯从技术人员的角度从字面意义上理解。

通常来说，面对同样笔业务交易量，普遍会认为对服务器产生的负载会比要高，但是在性能脚本能够在较快的响应时间中完成时，由于执行过程中每一个都需要发生两次迭代，导致了性能场景中在脚本部分停留的时间更长，因此反而能够得到比的更高的在线数，更高在线数带来的也就是更大的负载，也就是说：

同等业务量的情况下，线程所产生的负载完全有可能比线程所产生的负载要高。

为了避免发生这种问题，“并发（集合点）”的真正作用就体现出来了，通过集合点函数控制了的行为相对一致，降低了初始化过程和事务前后文请求产生的时间差影响。测试工具中并发存在的真正意义也就在这里，对集合点所理解的“并发”，和现场实际用户里面同时触发的请求关系不是太大。

分析“并发”需求时的一些典型：

某个业务系统里面有用户，但是能够访问这个系统的终端数只有个、或者所需测试的业务每个月上限是笔，那么最高在线用户数就不可能超过、业务量也不可能超过。所以，有些时候在分析性能需求的时候，去统计一个业务系统的用户数还不如去统计能够访问这个系统的终端数、甚至业务量靠谱。

某个业务系统里面，各个业务模块都不一样，那么就是说完成一笔业务交易，所产生的请求数也是不一样的，例如表单新增，有的需要填写个字段，有的只需要填写个字段，各个表单都不一样，那么为了更接近的去模拟用户现场负载，请求数都不一样的各种业务混在一起，并发数又应该是多少呢？

为了解决这些问题，需要首先考虑“并发”的粒度，以真实的业务场景为例：

把粒度控制在用户上来看，假定所有用户访问一次系统平均耗时秒，一个业务峰值会有用户在线，则。理论上，系统的性能需求是每秒要成功处理个用户的请求；

把粒度控制在事务上来看，假定所有用户执行一次完整的、成功的业务操作平均需要秒，一个业务峰值有笔所关注的业务需要去执行，则。理论上，系统的性能需求是每秒要成功处理笔业务交易；

把粒度控制在请求上来看，假定所有用户执行一次完整的、不管成功或者失败的请求操作平均需要秒，一个业务峰值有个请求需要去完成，则。理论上，系统的性能需求是每秒要成功处理个请求。