本帖最后由 kehaar 于 2017-12-29 11:24 编辑性能测试中，常见的一种场景是测试系统在大量请求下的响应能力和系统指标。因此，对性能测试来说，不可缺少的就是使用某种方法构造大量请求。 构造大量并发请求的工具，基本可以分为2种模式：1、 请求后，等待被测对象的响应后，继续下一次请求。这种方式我们称之为“乒乓球”模式，为了构造大量请求，通常使用多线程/协程并发请求，但每个线程/协程仍遵循“请求-等待响应”的“乒乓球”模式。2、 请求后，不等待被测对象的响应，而是直接继续请求。这种方式我们称之为“机关枪”模式。下面从几个不同角度对比两种模式： 1、适用范围：“乒乓球”模式更模拟正常客户端交互的行为，因此可以适用于各种被测对象，而“机关枪”模式只能适用于客户端与服务端不建立连接的场景，因此对于一些的简单的协议，如DNS等，适合使用“机关枪”模式 2、资源占用：“乒乓球”模式在请求发出到收到响应之间，会持续占用一定资源，因此占用资源较多，这点在被测系统性能恶化的情况下会尤为突出，而“机关枪”模式不等待和处理响应，因此占用资源较少，性能较好，在相同客户端硬件条件下可以提供更高的每秒请求量。 3、构造测试场景的难度：理论上来说“乒乓球”模式的行为更接近于真实客户端的行为，但是对于同时请求的客户端较多的场景，受限于性能，很难用“乒乓球”模式运行真实的客户端数量的线程/协程，而是通过减小请求时延的方式来模拟，举例来说： 测试某系统处理每秒1k请求的场景，从用户行为分析，每个用户约30s会请求一次系统，那么实际上在30s内，其实是有3w个不同的客户端在访问系统。此时最符合真实场景的模拟方式应该是：3W个“乒乓球”模式的客户端，每个客户端每次请求相差30s但是由于乒乓球”模式较占用资源，这种模拟场景很难达成，那么一般会使用减小时延和并发线程数的方式，例如：1k个“乒乓球”模式的客户端，并通过添加适当时延保证每秒请求数为1k这种模拟方式存在一个弊端：当被测对象的性能恶化（响应时长变长）时，请求的频率将得不到保证，对上面的例子来说，如果被测对象的平均响应时间达到1s以上，那就无法维持1k/s的频率，此时为了达到1k/s的频率，就必须增加并发线程/协程数，而并发线程数的增加又可能进一步导致被测对象的性能恶化，同时也会消耗更多的模拟客户端（测试工具）的性能。特别是在使用多测试客户端分布式访问被测对象时，对一个测试客户端参数的调整将导致其他被测对象响应时间的变化，从而影响其他测试客户端对象的请求频率。这使得测试人员花费过多时间在调整并发线程/协程数和时延参数上，难以轻松构造希望的压力场景 而如果使用“机关枪”模式，则客户端的行为可大幅简化，例如：100个“机关枪”模式的客户端，每个请求之间相差0.1s这个实现只依赖与客户端发送请求本身消耗的时间（这个时间不大于0.1s就可以实现），而与被测对象的响应时间无关，因此也不会受到其他测试客户端的影响。可以简单的构造稳定频率的请求压力 4、结果度量“乒乓球”模式会等待每个请求的响应，因此可以方便的进行测试结果的计算统计，而“机关枪”模式由于不等待响应，因此无法进行结果的计算统计。因此，“机关枪”模式基本不会单独使用，在使用“机关枪”模式构造大压力的背景下，还需要使用一个“乒乓球”模式客户端，以相对极低的qps对系统请求，来度量系统此时的性能。使用这种方式的前提，是小流量“乒乓球”模式客户端和大流量“机关枪”模式客户端的请求对被测对象来说是等同处理的，也就是说：1、两种客户端的请求来自同一个请求集合。2、被测对象没有使用基于IP或端口的的负载均衡方式（或“机关枪”模式客户端的源IP/端口均匀的覆盖了负载均衡的每个后端）3、“机关枪”模式客户端的请求没有触发被测对象基于IP/端口的流控策略 总结如下（红色代表优势）：客户端模式“乒乓球”“机关枪”适用范围适用于各种请求并发测试只适用于客户端与服务端不建立连接的简单协议请求资源占用高低构造测试场景的难度需要构造大并发数时较为复杂和不稳定可以简单构造稳定的大并发度量结果可以直接度量测试结果不能单独度量结果，必须结合一个小流量“乒乓球”模式客户端以抽样的方式度量测试结果由此可见，“乒乓球”模式客户端适用场景更广，因此常见的性能测试工具也以“乒乓球”模式为主。然而在特定条件下（无连接的简单协议、大并发）下，使用“机关枪”模式测试工具会更加适合，也更加节省资源。因此在性能测试过程中，我们应该学会根据测试场景的不同选择不同模式的工具。

本帖最后由 estmdan 于 2017-11-20 15:04 编辑2.1 关于操作主要内容：聊聊性能验证工作的约束和计划，表明性能工作的目的，预期达到的效果。当前性能测试主要从以下几个方面开展： 1. 模拟真实环境。 模拟真实交付的现网环境相似的性能测试环境，所有性能测试的服务器都放置在同一个机房，属于同一个网段，服务器与服务器之间的网络交互通过交换机进行，在这里性能测试既要结合场景评估网络可能带来的性能瓶颈，同时也要在自己的组网中注意规避可能出现的网络性能瓶颈 2. 性能测试数据分为基础数据和业务数据两部分。 性能测试数据库和功能测试环境相互独立。性能测试数据分为基础数据和业务数据两部分。基础数据，指为了使表中的数据达到一定的数量级而填充的数据，目的是测试出数据库索引是否足够优化、表空间、索引空间是否足够；业务数据，指为了使被测系统能够按业务逻辑运行起来的数据，简单地说，就是功能测试所使用的数据，目的是测试出SQL语句是否足够优化、代码是否足够优化等。从另一个角度看，一个指的是配置类规格，一个是能力类规格 3. 屏蔽缓存，模拟最坏的情况。 缓存，是页面性能优化的手段之一。对于非频繁变化的数据，可以在容器中缓存起来，提高读的性能，同时减轻数据库压力。另外，缓存失效后需要重启缓存，即在系统刚发布、重新缓存过程中，用户访问速度会变慢、数据库压力也会加大。为了避免类似系统刚上线，系统就受到Load过高的场景。在性能测试过程中，我们需要模拟没有缓存的场景。 一切测试的出发点均是指合理的场景内最坏的情况 4. 先单场景，后混合场景，确保每个性能瓶颈都得到调优。 性能测试过程中，选择先执行单场景，后执行混合场景的策略。单场景执行，可以详细测试到某个页面、某个功能点等单点的性能，这种方式有利于定位性能瓶颈，优化代码。混合场景，在单场景都优化完成后，按照一定的比例对各种场景进行组合，测试整个应用系统的总体性能表现。 5. 拆分，隔离分析，定位性能瓶颈。 性能测试过程中出现的小概率事件，往往隐藏着大的性能瓶颈。为了精确定位到瓶颈，需要将各个功能，或者一个功能的各个步骤进行拆分分析，然后在可能有问题的部分进行再排查，直到瓶颈定位到为止。 6. 根据性能测试通过标准，来判断被测性能点通过与否。 性能测试将结合性能基线，以及互联网的一些业界标准，来评估判断被测试点是否通过2.2 执行评估制定性能测试策略之后，在实施性能测试之前，需要对被测系统做相应的评估。实施前的评估，主要目的是明确是否需要做性能测试和确立性能点。性能测试一般要求系统要支撑至少半小时的测试压力，我们要对系统在测试前后状态，以及测试期间各项能力的表现作出分析和评估。 1. 关键业务。2. 可能的PV量。3. 逻辑复杂度。 关键业务 首要维度，是确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟客户息息相关的功能点。云业务批量购买，批量实施，服务目录展示，性能告警等等 如果项目（或功能点）不属于关键业务（或关键业务点），则可转入第二、三个维度进行评估。 日PV量 第二个维度，是界定被测项目各功能点的PV量。如果PV量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试；而且其关键业务点，可以被确定为性能点。例如，上述例子中的批量购买、批量实施。 如果PV量不高，系统压力不大，但却是关键业务点，则依据第三个维度来判断。 逻辑复杂度 第三个维度，是判定被测项目各功能点的逻辑复杂度。如果一个主要业务的PV量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，当某一个环节响应较慢，就会影响到其它环节，造成连带效应。 其它以上3个评估维护，是相辅相成、环环相扣的。在实际测试中，应该具体问题具体分析。例如，当一个功能点不满足以上3个维度，但又属于内存高消耗、CPU高消耗时，也可列入性能测试点行列，这就需要我们结合系统在测试中不断完善我们的性能测试策略 2.3 模型业务模型 当前方案根据个人理解设计各个业务的客户端请求模型，后期可以根据实际商用情况进行调整。根据请求的动态变化情况，常见的为四种类型——固定式请求模型、浪涌式请求模型、振荡式请求模型和动态式请求模型。以固定式为主进行性能测试。依照场景和实际商用需求确定业务组合测试模型（未完待续）