性能测试问题排查及调优的常规思路常见的性能测试中出现的问题都是千奇百怪，但其实在调优和找问题的方面都是有章法和 套路可寻的性能问题常见表现般服务器在出现问题时的表现会出现以下几种情况：1. 服务器崩溃：每秒事务数出现大幅波动，且前台或后台出现大量报错2. 服务器对压力不敏感：压力不停增加，但服务器处理速度无显著变化，系统处理能力稳定在一个较低的水平但不崩溃性能问题服务器硬件指标常见表现当出现性能问题时，服务器常见的表现会出现以下几种：应用服务器CPU居高不下：如果非计算类服务，一般是由于系统存在错误逻辑导致线程锁或有低级 错误（例如日志写入用了 system.out）导致，如果是计算类服务应用服务器内存使用持续走高， 一般是由于服务器产生大量实例积压导致，常见于大量session/线程大量堆积（一个session 一般 占用10-20M左右的jvm内存），但是为什么会导致session/线程堆积的问题要具体分析应用服务器磁盘交换率居高不下，顾名思义，大量的文件写操作在进行，如果业务逻辑没有频繁 读写文件，则需排查，首先排查日志写入应用服务器网络流量居高不下 ，常见报文一般是2K-20K左右，可根据并发数计算大致流量，若实际流量和计算明显不符，则需要排查到底是哪些连接在消耗流量，常见是一些图片、 js等资源文件没有设置本地缓存。
数据库服务器cpu居高不下，一般常见于大量全表扫描，大量物理读， sql执行效率低下等情况，要配合top10 sql进一步查询数据库服务器缓冲区命中率持续偏低，偏低一般是小于95%，常见于数据库配置有问题，联系 DBA进行进一步解决用户互空过事 报工内容繁琐 业务逻辑冗余数据库服务器网络流量居高不下，要结合考虑业务及应用逻辑分析为什么会有大量数据持续的在数 据库和应用服务器之间流动，并根据实际情况看是否能简化部分互交逻辑，减少带宽消耗性能问题排查一般过程:按照问题发生的概率和投入产出比来说，一般情况下，会按照下图逻辑进行性能问题排摸和调优在解 决SQL和应用配置问题后，基本已经解决了 90%左右的性能问题了应州调忧分析*Topl0 5QLat冲区伤中率请写锁无效厂吒余窗列*表空问信息 * JVM/（X *妻略*洁胡连接数数据库调优分析排查数据库和sql语句的问题常通过获取top 10 sql来定位最耗资源的sql语句，并分析sql语句来 确认性能问题数据库常见的性能问题表现为数据库服务器 CPU过高以oracle为例，列举一些常见问题：1） 数据表/字段没有索引或sql查询时，某条件不在索引上：这个问题在新系统的测试环境上最为常 见，常常是开发新建了表或字段，忘了加索引。
加上索引即可修复2） 表锁、行锁，这个是应用和数据库的共同问题，常见于几种情况（包含但不限于）：a） 最常见：Select for update之后没有及时commit掉b） 对某一张大表进行大量或全量 update的时候没有分批进行，而是一次性 update并commit，并且对该表的读取方式未使用脏读模式c） 自增订单号没有使用seque nee，而是通过数据库内某字段做控制在大并发的情况下，对一条记录进行频繁的 update3） 数据表有索引，sql查询的时候，索引未生效，一般索引未生效有以下原因（包含但不限于），需要 逐一排查：a） 使用不等于!=或 <>运算符b） 使用like的时候百分号/下划线等通配符在前，例如 "%_"c） 数据发生很大变动之后，表没进行分析，可通过表分析或强制索引解决d） 单独引用复合索引里的部分索引列，会不走索引或导致索引效果下降e） 字符型字段为数字时在where条件里不添加引号，隐式数据转换导致索引失效f） 在where条件中对索引列进行函数运算，如trim（）,如需对字段进行函数处理，则要建立函数 索引.g） 对索引列使用not in ,not exist运算符h） 日期时间类字段做索引，在查询的时候等号两边数据类型不一致，导致隐式数据转 换导致索引 失效，例如datatime查timestamp或者字符串查timestamp。
很多大公 司的编码规范中都 完全抵制使用日期时间类字段作为索引i） 使用了 is null导致索引（尤其是复合索引）失效，建议字段不要为 NULL，用0、特殊值或空字符串来代替j） 跨表空间查询导致索引失效，建议对单个表空间进行查询后，用union联合查询4） sql未经优化，例如使用多层嵌套查询，group by中使用了 having等问题5） 缓冲区命中率低于90%，一般来说，缓冲区命中率应该要高于90%，最好在95%以上6） 表数据过大，未进行分表或分表空间尤其是对于一些交易记录表，历史交易记录表、日志表等数据表应用服务器参数排查注意点出现任何性能问题之后，除数据库外，最应该排查的内容应当是对应用服务器的配置 参数排查，一 般排查以下问题：java内存/堆栈：未设置最大内存会导致服务器当大量并发发生时，无休止的使用内存和虚拟 内存导致服务器资源耗尽缺省值一般无限制或128m-256m进程池/连接数：未设置最大连 接数会导致当大量并发发生时，无休止的产生新连接/线程去处理请求，最终导致服务器资源耗 尽最大连接数设置过小，也会导致大量外链无法接入系统，返回连接超时另外连接超时时 间也不能配置的过大。
java内存GC:过于频繁的GC会对服务器的cpu产生持续性压力，并且会影响内存数据的可靠 性，gc间隔时间过长也会导致GC时cpu使用率产生井喷时增长因此如果需要调整gc策 略，需要找到平衡点日志配置：建议将日志按照天输出进行配置，并且重定向到指定磁盘或目录，并 定期清理，避 免由于日志输出导致磁盘满的情况日志级别：系统运行时，建议日志级别调低，尽量只打印error级别的日志系统核心参数： 一般常见于ulimit -a相关参数和sysctl.conf相关参数，用于控制系统级别的资源使用极限， 经常容易忘记配置的是 ulimit中的open files（-n）参数，linux的系统默认是1024，实际作为服务器使用时远远不够的另外 ulimit参数分系统级别和用户级别，都需要设置正确数据库连接池：这里单独拿出来是因为经常会遇到一种情况，即应用连接池很大，而数据库 连接池却只有5-10甚至更小，当产生大量耗时的数据库查询时，请求的处理链就会阻塞在数 据库查询上导致服务器资源耗尽，应用崩溃，而数据库层面却没有任何异常产生应用服务器代码排查注意点如果数据库和应用配置都没有问题，那就需要排查应用本身的代码问题了。
一般来说，如果能在 项目开发代码编写的时候就考虑性能问题，会让代码的总体性能和质量都得到比较大的提升从性能 测试角度，一般建议注意以下问题：如果是自己开发（含二次开发）的线程池，要考虑内存溢出，异常或者代码导致连接未释放 多线程的问题系统构架设计时，要小心并行转串行的逻辑模块会成为最主要的瓶颈对于一些数据库读写极其频繁的应用，可以考虑使用数据库长连接的方式尽可能的减少递归的使用，好的递归能提高效率，但写的不好的递归会极大消耗服务器资 源字符串拼接时，避免使用+号而是使用StingBuilder尽量减少正则表达式的使用对于连接，流等对象，有open就要有close，例如磁盘10,网络10,数据库连接等在处理异常时，如果能用选择判断，尽量不要使用 try catch除非不得已，否则不要在循环中使用 try catch，应该把其放在最外层（个人深刻体会）如果可以，循环内尽量不要创建对象引用除非必要，程序运行中尽量避免使用反射，反射机制真的效率很差避免一次性载入过大的数据/文件到内存，以免撑爆jvm，建议使用缓冲区读取的方式如果要使用嵌套循环，建议在使用前多做业务逻辑分析和确认，避免由于逻辑错误产生冗余 循环前端尽量对非敏感数据、不经常变化的数据、页面资源、脚本文件等采用客户端缓存，减少 服务器和客户端的互交数据量和互交过程。
java写日志的时候，禁止使用 system.out，必须使用框架提供的日志写入类常见性能测试监控工具枚举分析Oil]性能测试工具枚举 分析.xlsx。