当前位置：文档之家 › 性能测试之性能测试调优

性能测试之性能测试调优

  • 格式：docx
  • 大小：17.74 KB
  • 文档页数：5

1. 性能测试调优

1) 性能调优原则

1. 在应用系统的设计、开发过程中，应始终把性能放在考虑的范围内；

2. 确定清晰明确的性能目标是关键；

3. 必须保证调优后的程序运行正确；

4. 性能更大程度是取决于良好的设计，调优技巧只是一个辅助手段；

5. 调优过程是迭代渐进的过程，每次调优的结果要反馈到后续的代码开发中去；

6. 性能调优不能以牺牲代码的可读性和维护性为代价。

2) 性能调优基本步骤

1. 确定清晰的性能目标，并按优先级排列；

2. 利用科学的测试工具对应用程序进行测试，定位出性能瓶颈，列举出可能造成该系统瓶颈的因素；

3. 把服务系统拆分成组件： Web 层、业务层、集成层、持久层，分别进行调优；

4. 有系统的科学调优

➢ 遵循一定的程序：测试性能→找出瓶颈→假设造成瓶颈的因素→测试假设是否

成立→修改应用→再次测试性能。

➢ 确定影响性能的因素： CPU、 Memory、 JVM、 JDBC 还是其它因素。

➢ 找出主要的瓶颈，首先解决最容易的，再重复测试。

➢ 一次修改一个瓶颈，不要对不需要的地方进行调优。

5. 优化完成之后，进行性能回归测试； 2. DB常见性能问题

随着开源框架越来越成熟，开发人员在写代码的时候，更多的情况下会去参考其它人员的写法，所以代码层面的问题其实所占的性能问题比例并不会太高，更多的可能是开发框架的选择及使用上会出更多的问题（比如配置问题）。但是大量的问题会集中在SQL上。现在的ORM层更多的是把数据库操作当成对像来使用，最大的好处就是开发人员能通过很少的代码量就完成数据库层面的操作，大大提示了开发效率，不需要去写很多JDBC代码。但是数据库毕竟不能只当作对象来看来，它有自己的组织方式，有自己的索引机制，当你数据库量到一定程度的时候，这类框架就会相当吃力，因为当通过对象的方式来组织对象之间的关系，就会导致映射到数据库层面的SQL会非常的复杂。恰恰这种复杂并不是数据库执行引擎所期待的时候，就会导致各种慢查询。常见的DB问题主要有以下几种类型（以mysql为例）：

1) 引擎的选择

mysql 常用的存储引擎包括 MYISAM、Innodb 和 Memory，其中各自的特点如下：

MYISAM : 全表锁，拥有较高的执行速度，一个写请求请阻塞另外相同表格的所有读写请求，并发性能差，占用空间相对较小，mysql 5.5 及以下仅 MYISAM

支持全文索引，不支持事务。

Innodb：行级锁（SQL 都走索引查询），并发能力相对强，占用空间是 MYISAM

的 2.5 倍，不支持全文索引（5.6 开始支持），支持事务。 Memory : 全表锁，存储在内存当中，速度快，但会占用和数据量成正比的内存空间且数据在 mysql

重启时会丢失。

综上，建议绝大部份都设置为 innodb 引擎，特殊的业务再考虑选用 MYISAM

或 Memory ，如全文索引支持或极高的执行效率等

2) 索引问题

索引是对数据库表中一个或多个列的值进行排序的结构，建立索引有助于更快地获取信息。 mysql 有四种不同的索引类型：

 主键索此 ( PRIMARY )

 唯一索引 ( UNIQUE )

 普通索引

( INDEX )

 全文索引（FULLTEXT , MYISAM 及

mysql 5.6 以上的

Innodb ）

建立索引的目的是加快对表中记录的查找或排序，索引也并非越多越好，因为创建索引是要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间维护索引。

在设计表或索引时，常出现以下几个问题：

a) 少建索引或不建索引。这个问题最突出，建议建表时 DBA 可以一起协助把关。

b) 索引滥用。滥用索引将导致写请求变慢，拖慢整体数据库的响应速度（5.5 以下的 mysql 只能用到一个索引)。 c) 从不考虑联合索引。实际上联合索引的效率往往要比单列索引的效率更高。

d) 非最优列选择。低选择性的字段不适合建单列索引，如 status 类型的字段

3) SQL编写不规范引起的慢SQL

针对SQL编写导致的慢 SQL，优化起来还是相对比较方便的。我们在编写 SQL 时就需要注意与索引相关的规则：

 字段类型转换导致不用索引，如字符串类型的不用引号，数字类型的用引号等，这有可能会用不到索引导致全表扫描；

 mysql

不支持函数转换，所以字段前面不能加函数，否则这将用不到索引；

 不要在字段前面加减运算；

 字符串比较长的可以考虑索引一部份减少索引文件大小，提高写入效率；

 like % 在前面用不到索引；

 根据联合索引的第二个及以后的字段单独查询用不到索引；

 不要使用 select *；

 排序请尽量使用升序 ;

 or 的查询尽量用 union 代替 （Innodb）；

 复合索引高选择性的字段排在前面；

 order by / group by 字段包括在索引当中减少排序，效率会更高。

除了上述索引使用规则外，SQL 编写时还需要特别注意一下几点：

➢ 尽量规避大事务的 SQL，大事务的 SQL 会影响数据库的并发性能及主从同步； ➢ 分页语句 limit

的问题；

➢ 删除表所有记录请用 truncate，不要用 delete；

➢ 不让 mysql 干多余的事情，如计算；

➢ 输写 SQL 带字段，以防止后面表变更带来的问题，性能也是比较优的

➢ 在 Innodb上用 select count(*)，因为 Innodb 会存储统计信息；

➢ 慎用 Oder by rand()。

4) 分析工具

针对SQL问题，常用的工具有：

➢ mysqldumpslow

➢ mysql profile

➢ mysql explain

具体使用及分析方法在此就不赘述，网上有丰富的资源可以参考。

合集下载

性能测试方法

性能测试方法

- 1 - 性能测试方法

性能测试是指测量软件系统、硬件系统等在特定环境下表现出来的特征和性能，或者根据软件需求来分析系统性能是否可行性。性能测试不仅能够检查系统是否符合要求，而且能查看系统在极端情况下是否能够良好运行。它可以发现系统中出现的瓶颈，并提供可能的改进措施以提高系统的整体性能。

性能测试的主要目的是查看系统的响应时间、吞吐量、可用性、可靠性、容量和可伸缩性等性能参数。它可以帮助用户了解系统在不同压力下的性能表现，从而选择合适的系统设计及优化方案。

性能测试主要包括如下几种测试方法：

1.力测试：压力测试是测试系统是否能够在预期负载下正常运行的一种测试方法，它可以帮助分析在高压力环境下系统的表现，从而及时发现可能存在的问题，提高系统的稳定性。

2.载测试：负载测试是测试在一定的负载下，系统能够正确响应要求的测试方法。它可以帮助检查系统在许多用户同时访问时是否能够正常响应，并保证其可靠性。

3.能测试：功能测试是检查系统能够正确执行所有功能的测试方法。它可以帮助检查系统功能是否正确，及时发现可能存在的问题，从而提高系统的可用性。

4.定性测试：稳定性测试是检查系统在经过长时间运行后是否仍能保持正常性能的一种测试方法。它可以帮助识别可能存在的内存泄漏、死锁、数据损坏等故障，保证系统长期稳定运行。 - 2 - 5.能回归测试：性能回归测试是测试系统的性能变化情况的一种测试方法，旨在检查系统性能是否在软件版本更新后发生变化。它可以查看系统性能是否在期望范围内，并及时发现系统性能变化导致的问题，从而提高系统整体性能。

性能测试是软件开发过程中不可缺少的一环，可以帮助开发人员更好地理解系统的表现，并及时发现可能存在的问题，从而提高系统的可靠性和稳定性。上述五种性能测试方法都有各自的特点，可以按照实际需求选择合适的方法，结合不同的测试工具来提高系统性能，实现最高的质量。

如何进行性能测试

如何进行性能测试

如何进行性能测试

测量性能

要正确地调整性能，必须准确完整地记录每次测试的结果并进行维护。记录应包括：

（1）精确的系统配置，尤其是与前几次测试的不同之处

（2）原始数据和性能监视工具计算的结果

这些记录不仅指示应用程序是否达到性能目标，而且有助于识别未来性能问题的潜在原因。

在每遍测试中，运行一系列完全相同的性能测试；否则，无法分辨不同的结果是由于测试中的改动还是应用程序更改造成的。使尽可能多的性能测试操作自动进行有助于消除因操作者造成的差异。其他表面上是良性的因素影响性能测试的结果，如应用程序在测试开始前运行的时间。正如冷的汽车引擎与热引擎的性能不同，长时间运行的应用程序由于内存碎片这样的因素，其性能可能与刚启动的应用程序不同。

定义性能测试

性能测试期间，测量和记录性能目标中指定的度量标准值。达到全部性能度量标准（如思考时间、事务混合等）很重要。在这些约束下，测试应尽可能实际。例如，对应用程序进行测试，确定它在许多客户端同时访问它时的性能。多线程测试应用程序可以用可复制的方式模拟多个客户端，每个线程表示一个客户端。如果应用程序访问数据库，则数据库应包含实际数目的记录，并且测试应使用数据项的随机（但有效）值。如果测试数据库太小，数据库服务器的缓存效果将产生不符合实际情况的测试结果。如果输入或访问数据的方式不符合实际情况，则结果也可能不符合实际情况。例如，在主键上按字母顺序创建新数据是不太可能的。通常，测试装置必须接受用户指定的输入参数，如事务混合、思考时间、客户端数目等。然而，测试装置本身可以规定创建实际的随机数据的规则。创建了驱动应用程序的测试装置后，应该将所有运行测试的不变条件记入文档。最起码，这些条件应包括运行测试装置所需的输入参数。另外，应将如何设置运行测试的数据库记入文档。说明中应指定数据库不应包含前一遍测试所做的更改。说明中还应指定用于测试的计算机配置。在不同于应用程序所在的另一台计算机上运行测试装置，因为这样设置更接近生产环境。

软件性能测试

软件性能测试

第1章 软件性能测试基本概念

1.1 什么是软件性能

当我们提到软件性能测试的时候，有一点是很明确的：测试关注的重点是“性能”。那么，本书要解决的第一个问题就是：究竟什么是“软件性能”？

一般来说，性能是一种指标，表明软件系统或构件对于其及时性要求的符合程度；其次，性能是软件产品的一种特性，可以用时间来进行度量。

性能的及时性用响应时间或者吞吐量来衡量。响应时间是对请求作出响应所需要的时间。

对于单个事务，响应时间就是完成事务所需的时间；对于用户任务，响应时间体现为端到端的时间。比如，“用户单击OK按钮后2秒内收到结果”就是一个对用户任务响应时间的描述，具体到这个用户任务中，可能有多个具体的事务需要完成，每个事务都有其单独的响应时间。

对交互式的应用（例如典型的Web应用）来说，我们一般以用户感受到的响应时间来描述系统的性能，而对非交互式应用（嵌入式系统或是银行等的业务处理系统）而言，响应时间是指系统对事件产生响应所需要的时间。

通常，对软件性能的关注是多个层面的：用户关注软件性能，管理员关注软件性能，产品的开发人员也关注软件性能，那么这些不同的关注者所关注的“性能”的具体内容是不是都完全相同呢？如果不同，这些不同又在哪里？最后，作为软件性能测试工程师，不同层面的软件性能都需要关注，在关注全部这些层面的性能体现的时候，又应该注意哪些内容呢？下面我们从3个不同层面来对软件性能进行阐述。

1.1.1 用户视角的软件性能

从用户的角度来说，软件性能就是软件对用户操作的响应时间。说得更明确一点，对用户来说，当用户单击一个按钮、发出一条指令或是在Web页面上单击一个链接，从用户单击开始到应用系统把本次操作的结果以用户能察觉的方式展示出来，这个过程所消耗的时间就是用户对软件性能的直观印象。图1.1第1章 软件性能测试基本概念 ·3·

以一个Web系统为例，说明了用户的这种印象。

用户应用界面应用服务器DB服务器发出请求用户感受到响应呈现请求返回数据系统响应时间呈现时间

Wifi性能测试影响因素评估及调优方法

Wifi性能测试影响因素评估及调优方法

WiFi性能测试影响因素评估及调优方法

Evaluation of WiFi performance test factors and tuning methods

WiFi性能在准入测试中是运营商的测试衡量指标，也是比拼测试中的重点测试项目。由于WiFi处于ISM中开放频段，因此无线环境十分复杂，影响WiFi空口性能的因素也十分复杂。WiFi空口性能的影响因素不仅包括网关所配置的无线参数，还包含所处测试环境的情况。下面对性能有影响的因子一一列举，并依据理论数据和经验数据将影响程度进行量化。

1 参数配置因素

1.1 AP的无线参数影响

1.1.1 AP的保护时间间隔

为减少多径效应导致的ISI干扰，协议规定传输的信息符号间需保持800ns的保护时间间隔（GI）。在802.11n协议中为提升无线性能，有一项新的PHY层技术Short GI（400ns），该技术在在多径效应不明显的环境下，对单条空间流，Short GI相比于Long GI可以提升吞吐量10%，性能提升比是1.1108，近似为1.1倍。页面配置如下：

一般为确保家用环境下有较好的性能，网关出厂时默认为Long GI。若需要将空口性能提升，可以修改为Short。

Long GI适合场景：在AP工作在恶劣的工作环境中（特别是涉及到多墙体反射的多径环境下），使用Long（默认GI）较好；多径干扰环境下，或者环境干扰较大时，以Short GI发包容易造成丢包和重传，反而会降低性能。

Short GI适合场景：在环境干扰少，测试环境较为空旷无过多反射体的环境下，环境丢包和重传率很低的场景下，使用Short GI可以有效提升吞吐量。 串口设置方法：wl–i wl0 shortslot 1//设置为Short GI

wl–i wl0 shortslot 0//设置为Long GI

iwpriv wlan0 set_mibshortGI20M=1 //设置为shortGI