性能测试之性能调优 《一》

德实赋值

性能调优  <1>
前言
性能调优，无疑是个庞大的话题，也是很多项目中非常重要的一环，性能调优难做是众所周知的，毕竟性能调优涵盖的面实在是太多了，在这里我们蜻蜓点水般的来看看性能调优这项庞大的工程都有些什么过程，同时也看看这些过程中常见的一些做法。
一、应用系统性能评价指标
响应时间：尽快的给用户返回响应，体现系统处理请求的速度；
吞吐量TPS：每秒完成的事务数，体现系统处理能力；
并发性：业务请求高并发时，系统能否稳定运行；
扩展性：单机处理能力不足时，系统能否横向扩展。
TPS = 并发用户数 / 响应时间
<说明>
业界衡量一个软件系统性能的三个指标：TPS(Transactions Per Second)，QPS(Query Per Second)以及RT(Response Time)，其实前二者可以等价于写操作和读操作。如此说来，系统性能优化无非是提升读写的效率，对应到实际应用场景就是增加系统的吞吐量，最终对于用户的直观感受就是较低的响应时延。
二、性能测试前置条件
1、数据库表数据量准确
要和生产数据量保持一致，至少一个数量级。数据分布尽量均匀。
2、测试环境和生产一致
测试环境机器配置、参数、代码尽可能和生产保持一致（数据库服务器硬件除外）。
3、合理确定并发用户量
系统并发用户量有多种算法可以估算：
平均并发用户数：
C=nL/T(n是考察时间内用户登录数，L是用户平均在线时间长度，T是考察值时间长度)
并发用户数峰值：C’=C + 3*根号C
用户总量/统计时间*影响因子：
网银用户量100万，根据2/8原则， 80%用户在上午9点到11点，下午2点到4点之间登录系统，每次登录耗时1到1.5秒。则并发用户为：
1000000*0.8/4/3600*1.5=82.5，
1000000*0.8/4/3600*1=55
根据系统用户数计算：
并发用户数=系统最大在线用户数的8%到12%
根据TPS估计：
C=（Think Time + 1）* TPS，
网银用户思考时间10s，
C=（10+1）* 3=33。
4、预估各功能交易量，确定压测功能优先级
根据交易量从大到小排名，排名靠前的优先压测。
5、设置性能问题认定标准(性能指标:需求为准)
比如响应时间超过3s、TPS低于10、服务器cpu占用率超过70%、jvm堆内存使用100%、垃圾回收频繁、网络IO或磁盘IO达到瓶颈等……都可能是性能问题。
三、性能优化一般思路
1、找到性能瓶颈
性能瓶颈定义：导致系统TPS低、响应时间长、资源（CPU、内存、网络）占用高等问题的关键程序模块。提升该程序模块的性能，可以大幅度改善性能。
常见的性能瓶颈原因包括：数据库慢查询SQL、日志打印、xml大报文解析和格式转换、复杂业务逻辑、锁竞争等。
2、如何找到性能瓶颈
使用LoadRunner给每个接口的增加事务，记录其响应时间和TPS，最慢的那个接口往往是瓶颈；
分析慢操作的日志，查看是哪个操作耗时最长；
分析数据库快照，看是否有执行较慢或者全表扫描的SQL；
通过Javacore查看线程正在执行的代码，是大部分阻塞在IO上，还是大部分在进行计算。针对不同的问题，使用不同的分析工具。
<说明:>
Javacore 是一个当前 JVM 运行状态的快照。通过对 Javacore 的分析，可以了解在 JVM 中运行的应用程序的当前状态，比如是否“卡”在某一点上，或在某些代码上运行时间太长。
3、针对性能瓶颈进行合理优化
性能优化原则：
先优化瓶颈问题；
方案简单，尽量不引入更多复杂性，尽量不降低业务体验；
满足系统性能要求即可，不引入新的bug。

德实赋值

lsekfe

友情提示下 图片没有上传成功。

bbtte