常见的J2EE应用架构：web层（请求接入、负载均衡、页面渲染等）、应用层（业务逻辑实现）、持久化层（数据记录）。
性能分析过程
序号 步骤名称 说明
1 检查RT 模拟用户发起负载后的响应时间
2 检查tps TPS小时，响应时间大，说明系统性能良好
3 检查负载机资源消耗 检查CPU使用率，CPU负载（load Average）确认是用户CPU占用高还是系统CPU占用高
4 判断负载机是否有问题 排除负载机的性能问题，确保测试结果可参考
5 检查web服务器的资源消耗 1、检查CPU使用率，确认用户CPU和系统CPU的占用情况
2、检查内存使用情况
3、检查磁盘使用情况
4、检查占用的宽带
5、分析web页面响应时间的时间组成，确认是什么请求影响了性能
6 确认是否web服务器瓶颈 判断是否是web服务器硬件性能瓶颈
7 检查中间件配置 确认是否是此配置出问题
8 关注APP服务器资源消耗 关注CPU、内存、磁盘、IO，判断是否是APP服务器硬件性能瓶颈
9 数据库服务器资源消耗分析 1、CPU消耗、CPU负载
2、内存消耗
3、IO繁忙程度
4、数据库监控
10 是否SQL问题 1、定位最不合理的SQL占比
2、索引是否正常引用
3、检查共享SQL是否合理范围
4、检查解析是否合理
5、检查数据ER结构是否合理
6、检查数据热点问题
7、检查数据分布是否合理
8、检查碎片整理
11 其他 比如网络阻塞、磁盘IO瓶颈、热点等
硬件瓶颈
CPU CPU利用率过高，CPU利用率分为系统CPU（操作系统占用的CPU）和用户CPU（运行的应用系统） １、计算量大：运算、连接查询、数据统计
２、非空闲等待：IO等待、资源征用
３、过多的系统调用，调用操作系统提供的程序接口
４、过多的中断（中断是CPU用来响应请求的机制，如键盘的输入和鼠标的点击）
内存 内存的吃紧 1、过多的页交换和内存泄漏
2、JVM堆内存中有些对象无法回收，没有空间容纳新的内容，导致JVM崩溃，内存溢出，多数是程序原因
3、开始频繁的使用虚拟内存，多数是物理内存吃紧了
4、解决办法：a、加内存、加机器，b、减少不必要的调用，减少内存资源占用
磁盘 磁盘繁忙，数据读写频繁 磁盘的频繁读写导致CPU等待的情况会激增
解决方法：1.减少IO；2.更换更快的磁盘（包括条带化）
网络 网络流量过大 高并发系统由于访问量大，带宽需求会比较大，导致网络拥堵
优化方案
分类 问题 优化点 优化内容
TPS低/下降/不稳定
TPS下降 随着压测时间的进行，TPS逐步下降
数据库 优化点：添加索引
因为往库里添加信息，会有查重操作，随着添加信息越来越多，查询需要遍历整个表进行查重，消耗的时间也就越来越多，TPS会越来越低
清除库里的数据
有慢查询语句，优化SQL语句
应用服务器数据库连接池最大连接数由200改为7
把两个查询结果UNION操作在一起的sql，拆分成两个单独查询
网关 原因是在网关里鉴权需要调用其他接口，导致响应过慢
优化内容：网关鉴权操作通过提前预支数据处理，去除接口调用
代码、SQL 代码、把耗时长的做了规避处理，特定条件下需要加载的值，做了判断
添加索引
代码 1、主要是对xml解析慢进行了优化，减少了xstream对象的多次创建。
2、清应用和数据库磁盘。
磁盘 磁盘已满，清理磁盘
1、未压测时，数据库CPU使用率使用过半，关闭数据库定时跑批任务
2、数据写入Redis时，少写了一个表的数据，导致每次用到这个表的数据时，都要去数据库读取这个表的数据;解决办法：把这个表的数据放入Redis.
压测过程中监控mysql的等待进程率26%左右，并且出现响应时间持续上升,tps持续下降的现象 数据库 优化了索引，将最大空闲连接数改为100
TPS逐步下降，主数据库CPU使用率100%已饱和。 数据库 数据库维护人员找出2处慢查询语句，查询耗时均在7S以上，开发优化慢SQL
TPS波动大 TPS图波动较大 数据库 减少库查询
数据级别从10调至5
Tps低 Tps低不满足需求 数据库
日志级别调高一个级别
日志打印原因info级别的不影响，debug是严重影响的，关闭debug打印
减少不必要的关联表，和建必要的索引
代理人信息表新建主键
更改发送消息接口的后台处理逻辑扩大redis最大连接数
请求数据少，响应时间长且有少量失败，不满足需求 sp返回结果的转化方式、线程 1、对调用sp返回结果的转化方式进行优化
2、开启多线程时，获取执行数据，取消二次查库，直接从首次查库结果的集合中获取
平均响应时间长 响应时间长 数据库
减少不必要的索引
CPU使用率饱和
数据库CPU使用率饱和 数据库CPU使用率100% 数据库 在接口中的查询sql语句中添加索引
删除不必要的查询语句
cpu使用率非常高，并且响应时间很长 数据库 优化了查询规则和异步线程池调用
查询sql语句中添加索引
数据库饱和，报‘’time out‘’ 数据库 添加索引、增加数据库最大连接数
数据库服务器CPU饱和导致宕机 数据库 扩大数据库及Nginx连接池，数据库相关表添加索引后
Oracle数据库饱和 索引、SQL、表结构 创建了索引，优化了sql,和修改了一个表的结构
Nginx/tomcatCPU使用率饱和
Nginx/tomcatCPU饱和 代码、redis、tomcat 1、本项目代码中线程池由50上调至1000
2、redis 最大连接数由30上调至1000
3、tomcat jvm内存从6G下调至2G
10并发时出现大量的失败交易，tomcatCPU使用率饱和 应用线程池
mysql
代码
redis
1、应用的线程数由1024调到47540，
2、数据库初始化连接数由5改为50，
最大链接数由30改为100，
sql主要是保单表加了索引，
3、文件日志等级有debug改为info，
4、Redis最大连接数由100改为200
was服务器cpu使用率饱和 was服务器cpu使用率趋于饱和，导致tps遇到瓶颈 was服务器 was服务器扩容从2C8G扩容到4C16G
更改部分功能 去掉生成图片和截取图片功能，改为RSA非对称加密算法对数据加密
并发时报错
并发时报错
请求数堆积出现超时错误，导致tps呈下降趋势并出现少量失败交易 数据库 添加查询索引、条件查询的条件顺序整理、in换成exists、连接池最大连接数从100设置为500
支持不了高并发，报“未知错误” 调用的外围第三方接口代码逻辑有问题
并发时报错，错误信息：“未定义的异常”，定位原因为调第三方服务会员系统出现问题 优化点：判断会员系统是否绑定，由同步获取绑定改为异步后20并发无失败信息
并发测试时报错，错误信息“保存失败，请联系管理员 更换了获取连接的方式，原来是从自定义的适配器中获取连接，现在直接从连接池获取
20并发10分钟出现失败交易，错误信息ORA-12519数据库连接不够用 扩大数据库连接池的最大连接数由500增加至700后，20并发1小时无失败
出现504超时错误
（Connection timed out） redis
tomcat
1、线程池调了10倍 线程池 由50到500
2、redis 最大连接数 30到500
3、tomcat jvm内存从6G调到4G
网关 并发由于网关分发不过来导致
优化内容：增加网关服务应用部署个数至3台
数据库索引、Nginx 扩大数据库及Nginx连接池，数据库相关表添加索引
tomcat最大线程数由500调整为2000
mongodb连接池由1500调整为2000
数据库 1.登录接口：登录接口由原来的一次数据库查询改为不查询数据库去查redis缓存；
2.绑定微信接口：绑定微信由原来的两次数据库操作改为一次操作
会返回"object is not iterable"错误，日志返回''to many connection''。 修改代码逻辑中连接池200增加至1000
有大量失败笔数 因非线程安全导致出现大量系统异常
将全局变量删除更改为了局部变量（自己用自己的，不再公用）
Tomcat 测试环境由一台tomcat添加为两台后，问题解决
更改代码 修改程序多线程部分代码逻辑
代码
一个事物里update和insert操作了同一个索引造成的死锁优化了代码把更新改成先查询再按主键修改了
查询多并发会出现部分失败交易 代码逻辑 由于多线程并发访问时导致多个线程共享了同一个方法，旧的线程还未结束，新的线程已经进入，因而导致验签不一致，将处理逻辑由异步改为同步
压测过程中JVM老年代持续增长到100%，gc回收不掉。 应用框架、代码 程序代码的jdbc驱动由5.1.9升到5.1.46 ，并发框架Disruptor由3.3.4升到3.4.2
并发时，出现大量失败，错误信息：“系统未知错误RetryableException: Cannot assign requested address (connect failed) 堆内存及GC优化 ” 定位问题：由于同一时间并发访问较多，应用服务出现内存占用率过大，导致超时的情况；
优化点：将初始化堆内存扩大2倍，提高cpu的处理速度，-Xms2048m -Xmx2048m -Xmn1024m -Xss256k -XX:+UseG1GC
并发时报错网络繁忙 redis连接数 把redis连接数从200改为400
压测机问题
jmeter内存溢出 失败率0.01%，失败111笔，错误原因定位jmeter内存溢出； 更改jmeter配置文件原来:set HEAP=-Xms1g -Xmx1g -XX:MaxMetaspaceSize=256m修改后:set HEAP=-Xms3g -Xmx3g -XX:MaxMetaspaceSize=256m
压测机吞吐量饱和 压测机吞吐量饱和，导致tps遇到瓶颈 Linux系统 在Linux系统下压测