淘宝网每年的双11 活动都是对其服务器性能的挑战。因为在这一天所有商品半价，购物的用户量剧增。做为淘宝网的高层更多的关心在线用户数，用户交易量，总交易金额等，做为一名技术人员，我们可能更关心当天系统的吞吐量、每秒钟点击率以及系统资源的消耗情况等，对！这就是系统的性能。那么性能的本质是什么呢？我试抓住一些点来解释。
基于用户体验的性能测试
对于一个用户来讲，他不关心上面这些（系统的性能参数），大约有一部分的消费者会因为你的网站过于技术化或者性能问题而选择离开。换言之，如果你的网站速度太慢客户就会离去。这时人们的第一想法不是“哎呀，不知道站点的吞吐量怎样”，而是“简直是太慢了！我可没时间在这里等，到别出去吧”。现在想想，人们离开你的站点是否因为性能问题？所以，在做性能测试的时候除了关注吞吐量、点击率这些参数外，我们更需要站在用户的角度来测试实际的性能感受。如果你经过测试声称网站可以承受更多的用户访问，但实际的用户体验性能非常差，那么你做的性能测试又有什么意义呢？
现在市场上有大量的书讨论如何设计良好的性能，还有更多的书把重点放在如何使得站点更加直观、生动和易于炒作上。关于速度的好处也讨论过，但如何真正并优化系统来提高用户体验呢？那就是直接的用户体验测试了。有两点方法可以做一这点。一是可以把站点直接投入到能够进行数据采集和系统调优的生产环境中，并祈祷你的网站不会太慢或崩溃。另一个种明智的选择是模拟真实的用户活动，进行重复的测试和调优，最后再投入到生产环境。
“明确”的性能需求
当测试人员进行测试的时候，真正让他们感到困难的是不是测试工具如何使用，也不是如何对数据进行分析与系统调优。让他们感到困惑的是如何得到准确的量化的需求，比如：
- 网站可以支撑多少在线用户数
- 网站可以支持多少用户同时交易
- 电子邮件系统每秒钟可以处理多少封邮件
- 可以支持多少人同时浏览网页
类似这样的数据会出现在客户对系统的性能需求中，好吧，有了这些需求，我就开始性能工作了，这些需求真的很明确吗？
我们来看下面的例子，一个购买汽车的用户想知道：
这辆汽车开100公里的耗油是多少升。（对，就是他坐在里面试驾的那辆车）
如果你是一个严谨的汽车销售，不会马上会说这辆车每公里的耗油是多少。而是在大脑中快速的列出的汽车驾驶环境：
- 车上坐几个人？
- 车上带多重的物品？
- 路况如何，是高速还是拥挤的市区？
- 天气如何，温度如何，要开空调吗？
- 驾驶时间是白天还是晚上（是否要开灯）？
- 驾驶习惯是怎样的？
你唯一能做的就是继续向客户确认更明确的需求，很多时候客户也无法给出精确的需求。这个时候你就要多参考常规的情况下，参考同类产品，或尽量引导用户去明确具体的需求，尽量与客户达到统一的共识。
“假设”的测试环境
现在是不是觉得性能测试有太多的前置条件，它们或大或小的影响着测试的结果。
关于这些前置条件，或者我们称之为假设（assumption），我把一些做法归纳为三个阶段。
一：做了假设却不知道自己做了假设
比如前面提到的那个耗油的问题，有人的做法是我就开100公里看看，得出来是多少就是多少，比如9L。然后就告诉别人这个车的100公里耗油是9L。
问题是这样的结果对你是OK，因为你有切身的的体验，知道遇到的状况，可是测试的报告是要给别人，甚至你都无法直接面对或者沟通的人参考。这就会很容易误导别人，即便这不是你的本意，而且你自已也确定你是真实的记录了结果。这里的问题在于你并不清楚自己所做的假设，因为我们一直在做这样的假设。
二：做过多的假设
“当路面平坦，无任何红绿灯，风速5km/h只有一名70kg的乘客，时速稳定在70km/h，良好驾驶习惯，....的情况下，耗油是7.1L/100km。”
这样可能很严谨，但是对你的报告的读者而言，这样的数据有多大意义，因为他们没有你这么幸运，有这么良好的环境。
三：做必要和合理的假设
生活有时候是需要一些妥协和折衷，如果这些折衷是必要的和合理的。因为跳出来看，我们的测试需要提供有价值的信息，所以为了这样有价值的信息，做出必要和合理的假设是可以接受的。
好吧，也许这不是你想要的答案，但它是我目前给自己的解释和安慰。
性能测试环境需要在严格独立监控下管理，尽量保持与真实生产环境的一致性能。保持一致性应该注意哪些方面，等搜索虫师的《性能测试知多少---测试环境搭建》
“精确”的测试数据
对于一个严谨的测试员，我们的测试结果描述也相当精确，如：每个用户的访问时间为2.823秒，10分钟系统处理请求8634个。我之前一直认为，只要我把测试环境描述的很详细，我们的测试结果就是精确的。
实际上功能测试很容易得到测试结果，而性能测试很难得到精确的量化结果，我买了一辆车，开车去上班，去时车的各个功能非常正常，回来的时候车的功能也正常。我们通过功能测试很容易得出，这个车的功能没问题。
那么性能问题呢？再来看油耗情况，我去时油耗3.29升，回来时油耗3.42升，同样的一条路，同样的人开同样的车，那么是不一样的油耗结果？如果我再试一遍，可能还会有变化。 所以，我们很难得到精确的数据，但是这丝毫不影响我们测试结果的参考价值。
“宏观/微观”的性能测试
这也是一个有趣的队立。在做性能测试的时候，特别是整个产品的性能测试的时候，我们看到的是产品的核心功能和主要的大的核心模块，比如数据库、web服务器，核心的daemon（守护进程）等等。在脑海里，我们有一个架构图，哪怕你没有把它画出来。所以有时候，我们会想，性能测试对于产品的视角是宏观的，看大的组件，而不是具体的细节的东西。果真如此吗？看看下面的例子：
- 把daemon的log级别改为debug（log_level从2改到5）之后，性能下降了差不多一半。
- 日志记录器（Logger）的行为是分等级的：
分为OFF、FATAL、ERROR、WARN、INFO、DEBUG、ALL或者您定义的级别。Log4j建议只使用四个级别，优先级从高到低分别是 ERROR、WARN、INFO、DEBUG
- 日志记录器（Logger）的行为是分等级的：
- 关掉了一个cache
- 选项通常使用Cache以及写缓冲是为了提高系统性能，但由于Cache的使用可能改变访问主存的数量、类型和时间，因此Bootloader通常是不需要的
- 打开keepalive选项
- 为什么要有KeepAlive？链接建立之后，如果应用程序或者上层协议一直不发送数据，或者隔很长时间才发送一次数据，当链接很久没有数据报文传输时如何去确定对方还在线，到底是掉线了还是确实没有数据传输，链接还需不需要保持，这种情况在TCP协议设计中是需要考虑到的。TCP协议通过一种巧妙的方式去解决这个问题，当超过一段时间之后，TCP自动发送一个数据为空的报文给对方，如果对方回应了这个报文，说明对方还在线，链接可以继续保持，如果对方没有报文返回，并且重试了多次之后则认为链接丢失，没有必要保持链接。
- 打开DNS反向查询
- 所谓正向查找，就是说在这个区域里的记录可以依据名称来查找对应的IP地址。反向查找就是在这个区域里的记录可以依据IP地址来查找对应的记录名称
上面都是些细枝末节的设置，一个配置项而已，藏在DB的某张表或者某个ini里面。但是改变之后，得到的性能结果可能大不相同。这些都是否改变了我们以往的看法。
critical detail, 对，就是这个term。其实不光是这里说的测试，工作和生活中的很多事情都是一样，不是要不要关心细节，而是它是否critical。
所以，你还认为性能测试只是学习如何使用性能工具么？它需要一个长期的个技术的积累，我们的路还很长。也许，这里讲的不够本质，但性能测试这个领域，看到太多的新手在整天问工具的使用，学会了工具的使用就大言“我会（精通）性能测试。太多的公司叫新手的做性能测试，环境神马的也不提供，你找个工具对软件加压一下吧！哎~！这未免是太贬低“软件性能测试”了。