性能测试中“用户数”的概念浅析
在性能测试中，“用户数”是性能需求调研中最常见的指标之一，几乎所有的基于web的软件系统性能测试都要涉及到这个压力规模相关的概念。而这个概念本身却非常模糊，这种模糊会使性能测试场景在设计上有很多细节的不同，从而导致性能测试结果的巨大差异，最终使性能测试背叛了性能测试工程师，整个项目组得到的是与性能需求完全不相符的系统性能分析。可怕的是，大多数的性能测试工程师陷入其中还在津津乐道。“用户数”其实是一个广义的概念，它可以被进一步细化为注册用户数、在线用户数和并发。
注册用户数
注册用户数是指针对一个软件系统，有多少用户在这个系统中注册，从技术角度讲，就是有多少用户在数据库里留下了自己的可追踪痕迹。很多甲方在说系统压力的时候，喜欢在这个数字上面做文章，其实这个数字和系统上线后的压力没有什么必然的关系（通过设定预置用户的系统除外，具体分析见在线用户数）。这个就像某一地区人口很多但女人未必就很多是一个道理，人多只能说明人类这种生物比较多，但如果赶上了寺庙聚集区，可能女人就是一种非常罕见的物种了。
在进行性能测试需求调研的时候，这个数据也是需要调研的内容之一。注册用户数能够说明后台数据库某些数据表拥有的数据量的多少。这些表的大小会影响用户在进行注册、登录、修改信息等操作时候的速度，而这些操作恰恰是几乎所有性能测试都要涉及的。所以注册用户数的实际意义在于进行性能测试时，要在数据库的某些表中准备多少数据。
在线用户数
在线用户是指系统运行的过程中通过客户端成功和系统建立连接的用户，连接建立完成后，在线用户可能进入沉默（比如看页面显示的内容），这个时候没有请求，对服务器是没有压力的。在线用户数是指有多少个在线用户存在，如果没有明确定义用户发请求的频率，这个数字和系统的压力也没有直接关系，但是每一个在线用户都会在系统留下session，占用一些服务器内存资源和连接。所以在线用户数是从另一个角度对服务器的性能进行测试。
大多数系统都可以允许游客进入，在这样的系统中，在线用户数和注册用户数是没有什么必然联系的。有些系统是没有注册功能的，在运行系统的时候事先预置用户或由系统管理员添加用户，用户也只能通过登录才能进入系统。这样的系统，注册用户数便是在线用户数不重复登录情况下的极限值。
在线用户数在进行需求调研的时候可以分为三种情况，一般情况、峰值情况和极限情况。以某网上商城为例，假设在线用户会以正常的频率发送请求到服务器。在每天的早晨和中午，通常大多数人都在工作，所以没有到网上去购买东西或者浏览，所以用户数较少，而且这种状态在一天当中占据了绝大部分的时间，这就是一般情况。而到晚上20点到22点之间，结束了一天的工作，吃完晚餐，会有很多爱逛商场的人来到购物网站上浏览，在一天中这个时间在线用户数会形成一个小的高峰，在这个时段服务器处理的请求要几倍于一般情况，这就是高峰情况。而当有些节假日来到的时候，处于庆祝或者亲朋好友礼尚往来的原因，可能会有短暂的购买高峰出现，这种高峰时的在线用户数又会远远高于每晚的情况，如果服务器性能冗余没有做得足够高，在这个时候服务器的各种资源利用可能会处于极限情况，各种性能指标都会有所下降，这就是极限情况。
在进行性能测试的时候，三种情况可以酌情考虑，如果服务器资源冗余较好，可以直接略过一般情况，做高峰情况的压力。极限情况的压力测试可以适当在需求中放宽一些指标的要求，还需要做疲劳测试，通常极限情况持续一段时间后服务器的各种指标就会有不通程度的下降。这个时候需要考虑服务器的可靠性。
并发
并发在web服务领域是一个比较专业的词汇，只可惜因为其专业，太多的门外汉（甲方）很喜欢用这个词来表达需求，而实际这种表达是不准确的。并发并不是一个用户数的状态，而是以请求为单位的状态。在笔者以往的性能测试当中并发分为三种：同类并发、异类并发和持续并发。
同类并发是指在一个时间切片上有若干用户向服务器发送同样的请求，激活同一段代码，连接同一个库表。此时很可能服务器有很多计算资源，却无法全部利用。尤其是带有增、改、删的表操作，要进行锁表和解锁，即使还有很多空余资源，其他的请求还是要等待一个请求做完才能进行操作。
异类并发指在同一个时间切片上有若干个用户向服务器发送不同的请求，激活不同的代码，可能连接同一个表也可能连接不同的表。这种情况通常会造成服务器瞬时的计算压力，对服务器的突发计算能力要求较高。
持续并发是在服务器端看到的，指在处理某些请求的时候还有多少请求在等待处理，叫做持续并发是说在一段设定的时间内服务器的计算资源一直保持这种状态。这种并发对服务器的计算能力要求非常高，如果没有特殊原因，不建议使用。
通过以上的分析可以看到，并发操作只是在一个时间点或一小段时间内代表了系统的压力。在需求调研的时候通常这个指标是计算出来的，而不是通过调研获得。
压力
解释清楚了用户数的各个概念分支以后，大家会发现，以上的任何一种用户数都不能完全表现出来性能测试中的压力规模。但我们又确实使用用户数来进行性能测试调研，又用这个概念来在场景中进行压力规模的设置，那到底我们是如何实现的呢？请悉听下回分解。 这个概念上的确人些模糊，搞清楚很重要 回复 1# fairyox
不错，敬候下回分解。
页:
[1]
