作者：Apple，腾讯高级测试工程师。
以上三种情况，假设所有线程极致同步且系统性能足够，那么同一时间内（或者说同一瞬间），应该是有等同线程个数的请求同时到达系统，并同时被处理完再一起返回，此时线程就是并发，线程数就是并发数，这里理解应该没有问题。
目前腾讯WeTest服务器性能测试已经正式对外开放：
这篇文章其实憋了很久，最初仅仅是对吞吐量计算的个人兴趣研究，从理论建立到论证，因为担心一个不好被挑战的体无完肤，又各种查资料，找大牛讨论，然后又推倒重来，扩展了些内容，在这过程中，个人收获颇多，理清一些对性能测试理解的误区，些许心得体会总结如下，谈不上深刻，尽量朴实。
前言
随着部门业务的拓展，我们有了很多性能测试的机会，但在实战中，慢慢发现，我们对性能测试的理解并不如自己想的那么清晰，对基本概念和理论的混淆，导致对测试结果的不够自信，测试过程也常会面临质疑。所以这一次，我们不说性能测试怎么做，先一起梳理下性能测试的基本理论，分析这些理论如何在压测工具中产生影响。系统性能描述
描述一个系统的性能从来不是一句话或是一个数值的事。在IEEE的定义中：性能是系统或组件在给定约束中实现的指定功能的程度，诸如速度、正确性、内存使用等。所以性能测试报告中，对系统性能的描述应该是多方面的，如：执行效率、稳定性、兼容行、可靠性、可扩展性容量等；其中，执行效率通过并发用户数、响应时间、吞吐量、成功率、资源消耗综合体现。并发测试
性能测试有：负载测试、压力测试、配置测试、并发测试、容量测试、稳定性测试。其中，并发测试是测试多个用户同时访问同一个应用、同一个模块或者数据记录时是否存在死锁或者其他性能问题。 在实际的压测中，我们基本上都是设置多个并发，再进行负载测试、压力测试等，因为现实中，我们的系统就是面对多个用户的同时使用，并且，并发用户的数量，直接影响着系统资源的消耗，例如cpu、mem、网络连接、带宽，甚至于系统内部逻辑。并发怎么看？
所谓并发，它的特点是“并行”和“同时”。LoadRuner的并发很好理解，就是虚拟用户数。因为LR有个集合点，可以在所有虚拟用户初始化且到达集合点后，再一起执行后续操作，从而达到同时且并行的效果。 但目前在后台性能测试，我们自己开发的工具大多不带集合点功能，这时候使用者对并发的理解就会有点混乱。下面以长连接压测为例：最简单的一种，一个单进程单线程send工具，启动一次连续发m个包，这种其实属于单并发，请求串是一个接一个串行到达压测对象，一般都要再简单封装下，类似多进程并发：
还有一种，连接池模式，线程与连接数并不一一对应，维持工具到压测对象的连接数不变，线程们从连接池挑选空闲的连接持续发送请求。
以上三种情况，假设所有线程极致同步且系统性能足够，那么同一时间内（或者说同一瞬间），应该是有等同线程个数的请求同时到达系统，并同时被处理完再一起返回，此时线程就是并发，线程数就是并发数，这里理解应该没有问题。
但实际上，所有的并发不可能做到完全同步，压测过程中由于各种影响，比如：各线程初始化速度不一样，连接数不够，处理速度不一样等，导致在并行节奏上相互有了偏差， 这种现象在系统接近性能瓶颈时，会更加突出。所以会有同学疑问，这还能叫“并发”吗？ 这里引入“狭义并发”和“广义并发”的概念。 “广义的并发实际上是在一个时间内操作事务的虚拟用户，而狭义的并发指的是单位时间内向系统发起请求的虚拟用户，前者是“存在”，后者是“请求”，勿容置疑，压力不仅仅受成功发出请求的用户带来的压力，同时也受“存在”的用户影响。”
http://www.cnblogs.com/pohome/articles/2073283.html
这样看来，工具中的线程数设置，更偏像是广义并发，代表着在压测时间段内虚拟用户总数，这也是并发原始值。而在后续的压测过程中，在单位时间内，并发数可能会动态变化，这里是狭义并发。当工具产生的压力远未到系统性能瓶颈时，理论上，狭义并发=广义并发=工具线程数；当压力增加，系统响应时间增长，部分线程的请求处理正常，部分线程可能请求超时，那么同一单位时间内，同时向系统发起请求的用户数就不等于线程数了。那么我们如何实时掌握压测过程中可能变化的并发？《Method for Estimating the Number of Concurrent Users》一文介绍了一种并发估算法（网上有很多相关资料，这里不再累述）：
压力是什么？
压力就是并发在单位时间内对压测对象的请求数。在我们的压测工具中，有一个配置项专门用来设置压力，可能是所有线程产生的总压力，也可能是单个线程产生的压力。有些同学会在这里纳闷，为什么我设置了发送10w笔/s的请求，系统吞吐量的计算只有1w笔/s，是不是工具有问题？这里是因为混淆了压力和性能。 “压力不等于性能，压力只是检验性能的一种手段，对一个性能良好的系统，在一定的压力下，应该可以保持正常运转，如果超过负荷，则应该分流或化解压力，这也是我们需要检验的”http://www.cnblogs.com/pohome/articles/2073283.html例如：100个并发，1s内发送1w笔请求，如果系统的吞吐量计算大于或等于1w笔/s，说明系统承受住100个并发，1w/s的压力，我们可以增加压力继续测试，直到出现性能拐点；如果系统的吞吐量计算是5k笔/s，则说明，如果我们需要系统应付100个并发，1w/s的压力，解决方案要么提升系统性能一倍，要么扩容一台分流压力。要特别注意：压力是由工具制造，工具的最大性能决定施加的最大压力。我们在测试过程中曾经遇到压测系统还没到极限，工具已经到瓶颈的情况，这时候得到的压测数据是错误的。吞吐量如何计算？
我们在压测工具制作中，一直存在一个争议——吞吐量的计算。在性能测试中，吞吐量的计算有两种常见的公式：公式1： 吞吐量=并发数/平均响应时间公式2： 吞吐量=请求总数/总时长公式1、2大家应该都接触过，虽然看上去不一样，其实理论上都是ok的。首先我们可以从C = nL / T 推导：并发=请求总数*平均响应时间 / 总时长=》并发 / 平均响应时间 = 请求总数 / 总时长=》公式1 = 公式2 然后我们构建三组模型进一步论证：第一组模型
参考文献
性能测试解惑之并发压力http://www.cnblogs.com/pohome/articles/2073283.html软件性能测试流程简介http://wenku.baidu.com/link?url=9vfFqnNCsJ3Nv0cAl8_nb9SefIN17TFskt02E0yu75Zk6XVcHEz21rfrKrSfIFi7WhSqOWjsvz1k9fnVZ8SNn1GFbDpzjIzOWjBID1NfmOC软件性能设计与评价http://www.doc88.com/p-331430307121.htmlMethod for Estimating the Number of Concurrent Usershttp://wenku.baidu.com/link?url=w6eahwDiL_7Fyv5ekbpDGj946jICLtWyc7PphU63t7Mu8u84jdlGIMJSpBaxySUH49bU648a-1Y_xap9iSR4vuO1bMdYBOLhYdntDzyrRB7目前腾讯WeTest服务器性能测试已经正式对外开放：
体验地址：wetest.qq.com/gaps/
如何使用简单模式：wetest.qq.com/help/docume…
如何分析报告：wetest.qq.com/help/docume…
常用测试指标：http://wetest.qq.com/help/documentation/10098.html
