2、你们的系统能支持10000并发吗？

　　一些客户经常提出非常高的并发要求，此类客户通常对性能并不了解，或者之前有客户对其做了错误的解释，此时我们需要解释我们测试并发的概念：同时向服务器发出请求的虚拟用户数。（而我们通常会采用严格的方法进行场景测试：即采用集合点的方式进行操作。这种方式也即前面介绍的狭义并发的概念。）

　　另外，并发值需要考虑实际情况，需要根据实际的需求进行计算，与此同时，并发的影响因素并非仅仅是软件本身，还有网络、架构等等，TRS的产品性能测试往往给出单位机器的性能，用户可以根据这个基础值来构造实际架构。

　　3、你们的系统怎么才支持200并发？

　　并发的概念在于同时在处理某一件事情，而且系统一直保持这样的一个强度，并不是说总共只有200人，另外，我们测试的一般是单机，也是说，如果更好的性能要求，可以通过集群的方式来获得更优的结果，目前TRS的产品基本都支持集群的部署架构。需要注意的是，并发的支持除了软件本身，还受到网络、服务器性能等多方面原因的影响。

　　4、是否可以使用每秒处理事务来衡量。

　　性能测试的衡量指标除了响应时间，还有吞吐量、每秒点击数、每秒PV、每秒事务处理能力等，因此我们可以通过多种方式进行衡量，在更大意义上，各个指标间也存在一定的内涵联系，结合起来考虑更能够检查系统的性能。但受制于一些客观原因（如定制），在之前的报告中，指标衡量存在一定的限制。

　　5、响应时间与并发、压力是什么关系？这么操作的响应怎么才6秒，太慢了，你们的产品性能不行啊！

　　一般的，一定的并发下将对系统造成一定的压力，而对每个并发（用户）而言，所体现出来的性能多是直观的响应时间，在环境一定的情况下，响应时间越快说明系统性能越好。但此处需要清除一个问题，假定一个用户获取的响应时间是5秒，这5秒都在对系统产生压力吗？

　　后面这个是一个有趣而有意义的问题，我们知道这个响应时间是从用户发出请求到接收到响应的为止的总耗时，如果我们使用httpwatch之类的工具，可以很清晰的看到时间消耗的分布区间，我们可以把这个问题比作是向墙壁击出一个球，从击出到弹回来的时间即为响应时间。

　　大家打过壁球吗？打壁球的过程其实完美的诠释了用户发起请求到接受响应整个过程，可以我们可以把墙壁看作系统，打球者是用户，球是用户发出的请求，击打一次球包含有三个动作：击出球、球接触墙壁、收到弹回的球。三个过程加起来的总时间是这个请求（打出一发球）所得到的响应，但很显然，真正对系统产生压力的动作在于接触墙壁的时间，大部分的时间消耗在空中，即球在空中飞行时的时间，而这个飞行时间并不受系统控制，对应到常规系统，很可能是网络在传输过程中出现了问题。

　　这个壁球的例子实际上还可以解释一些相关的概念，比如并发是同时击出多个球，系统（墙壁）所能承受的大并发压力是墙壁的面积所能容纳的壁球数量，假定墙壁面积可以容纳1000个球，则墙壁瞬间可以接触的球的数量是1000个，这个是狭义并发的概念了，考虑到空中飞行，即将触碰墙壁的球，理论上的广义并发值要高于1000。击球时的力度可以理解为客户端的性能，性能好发球快，否则慢，只要系统性能没有达到瓶颈（比如墙壁没有坏），系统的性能是跟客户端呈正比的，即击球速度越快，返回越快。

　　因此，当遇到客户对响应时间有疑问时，我们需要解释的重点在于，压力在于球接触墙壁的瞬间，但性能测试考核的响应时间确实包含了两次飞行（发送与接受）的时间，而这个时间是受包含服务器性能、网络性能、客户端性能在内的多因素影响的，相信客户可以理解。

　　● 简单的结论

　　如果您觉得上面说的东西过于繁琐，以下基本概念可能更适合阅读。

　　1、并发分为狭义并发与广义并发两种，狭义并发指同一时间点开始做某件事情，广义并发指同一时间段正在做某件事情；

　　2、并发与被考察的场景是息息相关的，测试中所指的并发一般指同一时间段在做某件事情（被测事务）的用户数，在严格测试的环境下，我们会要求所有用户在同一时间点集合并执行；