● 理解并发

　　说完压力，我们已经知道，压力其实是一种作用力，当然，还可以理解为一种量的度量，比如列车的承载数，既然有量，肯定有速度，承载总量（吞吐量）是一定的，但速度却是变化的，我们早晚高峰的时候去乘地铁，当然是拥挤非常，但如果你晚上11点去做地铁，我可以很高兴地告诉你，你还会有座位！

　　原因在于，早晚高峰时坐地铁的人多，深夜时坐地铁的人少（这不是废话吗）。我们再来想想，高峰的时候可能同一时间挤进门的人很多，基本上门有多大，同时挤进去的人能把门给塞满。

　　那么这个并发（虚拟用户）是什么呢？

　　并发是有场景条件的，要看我们考察的是什么事情，我们再来想象一下地铁，在整个地铁大厅里（包括列车），有刚刚进站的，有正在买票的，有正在登车的，有坐在车上的，还有闲逛的，这么多人，但对列车有压力的，其实是已经在车上的这些人（包括挤车的），如果我们考察性能的系统是列车，很显然，重点关心的只需要看看车上现有的这些人。

　　再次强调，并发跟考察的具体场景是有关系的，即并发做什么，并发这个词，原始的翻译是concurrent，意为同时发生的，或同时存在的。至于同时做什么，要看我们定义了，同时在地铁大厅里，同时在地铁上，同时在挤地铁，考察的事情不一样，并发的意义不一样。

　　对地铁这个系统而言，每个时间都有新来的人，也有走的人，大家做的事情基本都相同，乘地铁。假定某个时刻地铁大厅中有10000人，检票口候车的有100人，刚刚开走的地铁上乘有2000人，那此时对考察的系统（列车）而言，并发是2000人，而如果考察的是检票处，则并发为100人，同样，如果考察的系统是地铁大厅，那此时的并发是10000人。这种并发我们一般称之为“广义并发”。

　　广义并发有点类似与通常我们所说的在线用户，但存在关键的区别，即并发用户针对的是某一件事务，譬如注册、登录、上传、浏览等，而在线用户是一个很泛的概念，一般包括前面所述的所有事务，可以理解为一个事务集合。

　　在性能的理论中，还有一个概念，simultaneously，翻译为同步的，当前，为方便计算，我们一般把“同步”理解为“同1秒”，也是说，这个同步的是单位时间内发生的数量。也即我们通常所说的“狭义并发”。需要注意的是，实际的测试中经常会遇到被测事务响应时间低于这个1秒的单位时间，此时的并发计算仍需要按1秒计算，具体参见“我们的定义”中的说明。

　　很多时候，我们（特别是客户）往往搞混了这两个并发的概念。对系统来说，广义的并发实际上是在一个时间内操作事务的虚拟用户，而狭义的并发指的是单位时间内向系统发起请求的虚拟用户，前者是“存在”，后者是“请求”，勿容置疑，压力不仅仅受成功发出请求的用户带来的压力，同时也受“存在”的用户影响。

　　换种理解方式，并发考察的是系统的处理能力，多能支持多少用户同时处理某件事务，而不是压力发出端发出的请求。

　　除此之外，并发作为一个量化的指标，是对应着具体的取值的，因此，很多系统会去寻求大并发，实际上，我们来回顾5号线的承载力的例子，核定载客1424人，这种情况可能考虑到乘客的感受（还算舒服，站着也算，哈哈）

　　● 理解我们的定义

　　在我们已经做过的很多测试中，都有并发这个概念，当然也包括我们很多开发人员，所谓的并发是怎么定义的呢？

　　客观的说，我们的定义比较接近于“广义并发”，但有所不同。这与我们的考察对象（web系统）、衡量事务（通常我们衡量的都是单个事务，很少把多个事务放在一起处理，原因在于尽量避免事务的耦合性所带来的影响）有关，具体到地铁的例子，如果我们考察的系统指“地铁大厅”，那么我们所谓的并发一般通常指同时进入地铁大厅的人。而如果我们考察的系统指“地铁列车”，那么我们所谓的并发则指同时进入站台的人。

　　在实际的产品测试中，比如我们在测试IDS登录的时候，如果说，支持800并发，其涵义为“支持800个虚拟用户同时进行登录操作”，需要说明的是，这个同时并非指同一秒，要知道，并发本身是没有单位的。在800并发下的结果如何，要看响应时间，这个问题本文不进行仔细阐述。如有兴趣可以参考相关资料。

　　测试中，我们也会考虑“狭义并发”的情况，但狭义并发需要考虑到被测系统的入口，比如，假定地铁总共有10个入口且全部开放，每个入口只能容纳1个人进出，则“狭义并发”下大值是10？不一定！因为我们还没有考虑速度问题，前面提到，狭义并发的单位是秒，如果每个人通过每个入口的耗时是1s，则大“狭义并发”值是10，如果通过的时间少于1秒呢？还是按1秒算，比如还是这个情景，乘客通过入口的耗时假定为0.1秒，则大狭义并发是10/0.1=100了。

　　简单点说，我们可以这么理解实际工作中的并发，被测的事务总得有人（其实是虚拟的用户）来做，对吧，同时允许多少用户来做这件事情呢？这个多少用户是我们需要的并发值。