前言：之前一直做的软件质量工作，有过一些经验和一些不太成熟的思路，尽管与现在从事产品运营不同，但无论是内涵还是联系，都是非常紧密的，无论如何，我都会继续关注产品的质量问题。

　　上周跟一朋友阐述性能中并发的概念，叽里咕噜一大通，完了兴致勃勃地让她总结一下，她说了一句：感觉你研究的东西太初级，并发这种概念，太简单，没什么好说的。我听了差点没晕倒，估计她也晕了，真是失败。

　　并发真的这么简单？性能真的如我们所理解的那样？

　　也许并不像我们想象的那么简单，之所以我们去探究这些基本的概念，是因为在实际的工作中，我们发现，很多问题到后才发现，根源在于概念没有统一，抑或没有理解，而无论作为研发人员，还是顾问、销售人员，我们除了自己理解，还需要与客户交流沟通，因此，深刻理解并能通俗易懂的表达出来是非常重要的。

　　由于软件性能的范围比较大，我们将选取几个典型的问题进行探究，相关概念的理解与分析将逐步进行公开。

　　● 如何考察性能

　　这个问题相信很多同事都了然于心了，基本都有自己的理解，我们也很少接到不懂性能的反馈，但很多人甚至包括客户，都把响应时间或者并发用户作为衡量性能的惟一依据，支持10000并发？性能好！响应时间1秒？性能好！有些时候我们也会接到客户一些要求，让我们哭笑不得，某次一客户要求我们的产品支持10000并发，有点汗，哈哈。

　　实际上性能是一项工程，严格地说，性能是在某一个特定环境下，系统所表现出来的大事务处理能力。如果我们将这个问题细化，性能取决于具体环境，取决于系统架构，取决于软件与服务器的优化等等，也是，我们所提供的内部测试报告是具备一定的前提的（在一定的网络或硬件环境下），如果我们的架构是包含了10台机器的集群，而客户方提供的却是2台PC机，这种条件下还要求测试结果保持一致，有点为难了。

　　尽管性能有很多范围、指标、概念，比如响应时间、吞吐量、并发用户、软硬件负荷等等，但对普通用户来说，并发用户数与响应时间这两个概念还是为直观与普通，认可度也高，搞清楚这两个概念非常重要。后面我们会逐步阐述其他概念。

　　● 理解压力

　　在谈起并发这个概念之前，我们先来说说压力，对系统而言，性能问题归根到底，都会体现为实实在在的压力。因此，我们一般说的“你这个系统的性能高能到多少？”，其内在含义指的是“系统所能承受的大压力是多少”。

　　那么压力究竟是什么呢？

　　我突然想起天天坐的地铁，没有比坐地铁这件事情更便于形容性能与压力了，哈哈。话说我每天在立水桥南上地铁，是考验体力耐力心理素质的事情啊（说岔了）。

　　我们可以把一班地铁列车看成是一个被测的系统，对于这个系统而言，其压力显而易见，是列车中所有的人，比如北京地铁5号线，每列车的定员人数是1424人，折合每节车厢237人（当然包括站着的），而多容纳是1820人，折合每车厢303人，这个总承受人数。

　　其实是系统（也是列车）的大设计承受压力（也是吞吐量了），当然，北京地铁比较变态，超员现象比较严重，我每天占用的面积还不超过10平方厘米（脚踮起来了），实际大负荷估计超过2000了。对列车而言，超过大负荷是比较危险的，要么是拉不动（这个估计可能性不大），要么人挤坏（君不见每天争吵哀嚎无数）。

　　如果超出设计负荷值，系统会存在危险，危险是多方面的，因此，一般的，系统应该具备超出负荷的处理预案，对照到地铁，高峰时期会进行限流。

　　搞清楚这个问题后，再来看看常规的系统，好理解了，系统的压力是什么呢？压力是对被测系统而言的，只要系统在处理事务，有压力，这种压力不仅仅体现在网络上（数据的吞吐），还体现在服务器上（如CPU、内存等），因此，我们不要混淆了吞吐量与压力的关系，应该这么说，在一些web系统上，吞吐量可以在一定程度上反映系统承受的数据压力。

　　另外，我们需要清楚，压力不等于性能，压力只是检验性能的一种手段，对一个性能良好的系统，在一定的压力下，应该可以保持正常运转，如果超过负荷，则应该分流或化解压力，这也是我们需要检验的。