最有效的七大性能测试技术

lsekfe

进入互联网时代，性能测试显得越来越重要，移动应用、web应用和物联网应用都需要进行性能测试和性能调优，而进行性能和负载测试会产生了大量的数据，这些数据难以分析。除了数据分析，我们还会遇到其它一些困难和挑战。
　　今天我们就介绍七大高效的性能工程（测试）技术帮助你应对挑战，能进行有效的数据分析，高效地完成性能测试和性能调优。
　　1、识别基于层的工程事务
　　在典型的性能测试工具中，加载脚本会包含事务处理或有序的API调用，以完成业务工作流。例如，我们正在为一个物联网应用程序创建一个性能管理工具，这个脚本将包含代表一个设备的事务处理逻辑或行为。
　　工程脚本包含针对部署的特定层（如网络层、应用层、消息层、数据库层等）的单个事务处理。通过发现工程事务处理的退化，我们可以隔离需要集中精力的部署层。为此，我们需要确定哪些事务到达哪些层。如果在这方面有困难，就不得不向开发或基础架构支持团队寻求帮助。

每个部署都是独一无二的，但这里我们可能会遇到的一些和层次相关的问题：
　　● Web层：获取静态非缓存文件的事务。
　　● 应用程序层：执行一个方法并创建对象的事务，但就停留在这里，没有去访问数据库层。
　　● 数据库层：需要从数据库查询的事务。
　　让每个工程事务都有自己的脚本，这样我们就可以分别绘制出每个工程事务的命中率（TPS）和响应时间值。在每个工程事务之前使用一个恒定的思考时间（例如15秒）来间隔执行时间，并创建一个一致的采样率。
　　2、监控KPI
　　前端KPI（关键性能指标）通过关联用户负载、TPS、响应时间和错误率来显示当前的容量。被监视的KPI可以完整地说明为什么应用程序在某个工作负载级别上开始降级。命中率和空闲资源是每个硬件或软件服务器的两个具有启发性的KPI。

命中率将随着工作负载的变化而变化。在递增负载测试中，随着工作负载的增加，命中率也随之增加。以下是可以监控的命中率示例：
　　● 操作系统：TCP连接速率
　　● Web服务器：每秒请求数
　　● 消息传递：入队（Enqueue）和出队（dequeue）统计
　　● 数据库：每秒查询数
　　请记住，每个部署都是唯一的，因此需要确定每个服务器的良好命中率是多少，然后连接上所需的监视。
　　一般我们倾向于监视空闲资源KPI，因为与使用的资源不同，空闲资源的趋势与工作负载相反。正因为如此，可以很容易地在图上识别瓶颈（但如果免费资源不算在内，就得使用已使用的资源）。无论目标是哪个资源，如果它有排队策略，请确保添加一个排队计数器来显示正在等待的请求。以下是可以监控的免费资源：
　　● 操作系统：CPU平均空闲
　　● Web服务器：等待请求
　　● 应用服务器：空闲的工作线程
　　● 消息传递：进入/退出队列等待时间
　　● 数据库：线程池中的空闲连接
　　要确定相关的监控KPI或将它们连接起来，首先要研究部署的架构图。接收或转换数据的每一个接触点都是潜在的瓶颈，因此是监视的候选对象。所监视的KPI越相关，性能描述就越清晰。
　　开始启动工程脚本进行性能测试，完成业务工作流的负载测试。先设置一个缓慢增长的测试（例如，每15秒增加一个用户，最多增加200个虚拟用户）。测试完成后，将所有监控的KPI绘制成图表，并确保它们与测试报告的TPS/工作负载之间存在直接或反向关系。要有耐心，把一切都画出来。从这个测试中收集的信息，在识别性能瓶颈上非常有价值。

另外，设置监视间隔以收集每个持续负载的三个值。在本例中，因为每15秒添加一个用户，所以希望每5秒获得负载测试工具示例，因为三个值将作为一个平台图，而一个单一的值将作为一个峰值图，三个值才能形成趋势。
　　也许不是所有的资源都将在架构图的审查期间被捕获，所以启动一个快速增长的负载测试，来发现一些新的资源或新的KPI。这只是一个探测，看看哪些进程和操作系统活动会启动。如果注意到一个外部过程，就可以作为一个KPI候选对象添加到脚本中。
　　3、减少要分析的事务的数量
　　进入了分析阶段，我们需要显著减少绘制并用于分析的事务数量。试图分析数百个带标记的业务事务是没有效率的。所有这些业务事务都使用部署的共享资源，因此只需选择其中一些事务，就可以避免分析瘫痪。至于选择哪些事务，完全取决于应用程序的特性。
　　例如面向单用户负载测试的结果，选择访问页面、登录、响应时间最长的业务事务和响应时间最短的事务。
　　还要包括并绘制所有工程事务。工程事务的数量取决于部署中有多少层：5层等于5个工程事务。

现在，不是分析在模拟实际负载的负载测试中执行的所有事务，而是只绘制一个子集，响应时间的图表将不会那么混乱，也更容易分析。但创建性能报告时，需要包括所有业务事务的响应时间。
　　使用分析技能来查看哪个工程事务首先开始降级。命中率和响应时间都将揭示需要集中精力的地方。
　　4、确保可重复的结果
　　对于每个测试场景，运行相同的负载测试三次直到完成。对于这三种测试执行，不要调整或更改性能测试工具中的任何内容：不要修改运行时设置、不要修改测试脚本、不要修改测试的持续时间、不要修改负载模式，更不要修改性能测试环境。只允许数据重置或服务器回收，并且只允许在测试运行之间将环境恢复到基线。
　　每个测试场景运行三次，并进行初步分析，以在同一时间验证结果或TPS平台。
　　5、增加负荷
　　增加负载，就是创建并发用户负载场景。先创建一个缓慢增长的阶梯场景，它允许为每个负载集捕获三个被监视的KPI值。换句话说，在添加下一组用户之前，配置缓慢的用户斜坡以维持一个持续时间。例如，如果您每次增加10或100个用户，并每隔5秒收集KPI，那么在增加到下一个负载之前，每个负载集至少运行15秒。是的，这延长了测试（通过减缓斜坡），但结果更容易解释。不能持续的KPI指标并不是一种趋势。
　　当性能测试时，遵循“一半-两倍”定律会极大地简化性能工程方法。从实现一半的目标负载开始，如果应用程序能加载到一半负载，然后可以把它翻倍到目标负载。如果不能加载到一半负载，则再次将负载减少一半。如果有必要，可以反复这样做。继续减少一半，直到得到一个可扩展的测试，即使只有10个用户，而虽然目标是10,000!
　　6、利用可视化来发现异常
　　如果知道一个完全可伸缩的应用程序是什么样子的，我们就可以迅速发现异常。因此，研究一下架构图，看看在一个完全可伸缩的应用程序中应该发生什么，并将其与测试结果进行比较。
　　● 会发生什么?
　　● 什么会发生，什么不会发生?
　　这些问题的答案会告诉我们应该把注意力集中在哪里。例如，随着用户负载的增加，应该看到web每秒请求数、应用服务器的活动会话、数据库连接数、CPU使用率等都相应增加。通过使用可视化的强大功能，可以大幅减少调查时间，因为您以快速发现不代表可伸缩应用程序的条件。
　　粒度对于KPI监视和可视化分析都至关重要。通常，如果一个测试运行很长时间，加载工具在绘制结果图表时将使用更细粒度的间隔。拥有更多的KPI数据点，使分析更容易，但清晰的图表也可能会扭曲了测试结果。
　　7、寻找KPI趋势和停滞期，以确定瓶颈
　　当资源被重用或释放时（就像JVM垃圾收集或线程池一样），KPI值会有起伏。把注意力集中在数值变化的趋势上，而不是绝对的偏差上。用我们的分析眼光来判断趋势，确定第一个出现的瓶颈的可靠技术是用图表表示前端KPI的最小响应时间。使用粒度来分析和识别从其底部出现的第一次突变。最小响应时间内的提升不会有明显变化，而一旦资源饱和，就会突破最小响应时间，所以第一次突变这点会比较精确。随着部署接近第一次出现的瓶颈，TPS或每秒命中数将趋于稳定，响应时间将立即降低或增加，错误率是级联症状。命中率中第一个出现的平稳期表明吞吐量有限制，所以我们等工作只是在监视的命中率KPI中识别它出现的第一个图形平台，这也是为什么主张为每个持续负载收集三个监视指标。一个数据点值只能给出一个峰值，但三个数据点可以呈现一个平稳区间，而这很关键，帮我们发现系统受到限制，要么是软件限制，要么是硬件限制，但绝大多数瓶颈都是软件限制，任何硬件都无法解决这一问题。
　　通过调优可以提高可伸缩性，通过优化来提高吞吐量，进一步减轻了软件限制，允许应用程序在云部署中有效地向上和向外扩展，可以为公司节省大量的运营费用。所以建议对峰值负载条件进行负载测试，然后注意哪些资源已被分配来适应工作负载。然后将这些资源投入到部署中去。只在超出预期峰值负载的情况下使用弹性云。
　　记住，隔离第一个出现的KPI是很重要的。不要停留在偶然发现的第一个平台期，然后宣布胜利，因为这可能是一种症状，而不是根本原因。过早的下结论将使我们在配置更改和重新测试方面浪费数小时的时间，结果却发现性能退化同时发生，这意味着负载遇到了相同的瓶颈。
　　注意：如果有两个或更多的KPI看起来像竞争条件，通常可以通过覆盖KPI图表来获得更清晰的可视化，从而看到哪个平台期首先出现。如果这不起作用，那么设计一个新的负载测试，在加载接近相同的峰值容量负载时减缓加载速度。慢慢地向下移动以收集更多的数据点，这将使结果更清楚。