本文是笔者实习时待在一家测评公司，由于公司做性能测试不负责调优，只提供简单排查指导，总之，很多套话。。。。
资源问题
| 现象 | 建议 |
|---|---|
| CPU资源过高 | 建议排查问题产生原因，确认服务器资源是否充足，避免资源占用较高影响系统的整体效率 |
| 建议排查优化相关程序，减少对资源的占用，避免资源占用较高影响系统的整体效率 | |
| CPU资源过高（应用） | 建议开发人员优化程序代码或增加应用服务器的CPU资源 |
| CPU资源过高（数据库） | 建议开发人员优化SQL语句、尽量减少对全表的遍历查询或增加数据库服务器的CPU资源 |
| CPU间歇性调用 | 建议开发人员确认连接数是否充足 |
| 内存存在持续被占用且没有被释放的现象 | 建议开发人员确认服务器内存分配机制是否合理或增加服务器的内存资源 |
| 剩余内存不足XXXM | 建议开发人员确认内存的分配是否符合系统配置要求，避免由于服务器占用大量内存导致系统宕机，影响用户正常使用 |
| 磁盘写入量高 | 建议排查应用系统的LOG日志级别是否合理，确认系统中是否有冗余代码 |
| 磁盘写入量高（含新增及其他测试点） | 针对测试程中Mysql服务器磁盘写峰值150M/S的现象，请排查除测试点产生的磁盘写外，是否存在其它额外写操作，确认磁盘写入量正常。 |
| 应用服务器根目录下磁盘空间已满 | 建议运维人员定期清理磁盘空间，避免由于服务器磁盘空间已满，造成系统无法正常访问 |
响应时间过长
| 现象 | 建议 |
|---|---|
| 图片及css资源文件过大 | 针对平均响应时间过长的问题，建议在不影响系统访问的情况下，压缩页面大小（图片,CSS样式和JS等）资源，提高交易的执行效率。 |
| 查询时间过长 | 经过开发人员采用数据库的二级缓存机制和针对业务数据的缓存管理机制,减少对数据库中业务数据的访问频率后 |
| 测试点中包含地图资源，造成查询时间过长 | 经过排查是由于网络带宽出现瓶颈，经过开发人员采用zip压缩传输的方式，地图控件采用浏览器缓存等方式，减少传输过程中的网络资源占用 |
其他情况
| 现象 | 建议 |
|---|---|
| 集群中部分服务器资源无占用 | 建议开发人员确认流量分发机制是否合理 |
| 应用服务器和数据库服务器在一起 | 由于应用服务和数据库服务部署在在同一台服务器上，势必会造成应用和数据库的资源争用，针对此种情况，建议分开部署应用服务器和数据库服务器，避免因为资源争用影响系统的处理效率 |
| 随着业务数据的增长，服务器压力逐渐增大，为了避免服务器异常现象的产生，建议应用服务器与数据库服务器进行分离，避免应用服务和数据库服务抢占服务器硬件资源，使服务器长期处于风险状态。 | |
| 两个系统部署在同一台服务器上 | 建议分开部署两个系统，避免由于资源争用影响系统的处理效率 |
| 接口测试中接口调用成功，数据和需求不符 | 针对XXXX接口和XXXX接口测试过程中接口调用成功，查询结果为空，与接口文档描述不符的现象，确认相关接口返回是否正确。 |
| 数据库服务器无压力 | 针对数据库服务器无压力的问题，建议排查数据库是否部署在XX.XX.XXX.XX服务器上，确认数据库服务器无压力的原因。 |
| 测试环境和生产环境不一致 | 针测试过程服务器内存持续被占用且没有被释放的问题，建议运维人员在生产环境下对服务器配置参数做相应的修改。避免由于服务器内存不足，导致系统无法正常访问。 |
| 测试环境和生产环境不一致 | 由于性能测试环境与生产环境存在一定差异，建议将性能测试环境下所做变更（如：中间件连接数配置参数和数据库服务器索引配置等）应用到生产环境 |
| 稳定性运行2.5小时后，出现大量的失败事务 | 通过开发人员修改Tomcat配置信息以及修改后台代码，使用单例模式处理Connection、Session |
| 测试环境下数据量过少 | 由于测试环境下系统数据量过少，为了避免系统上线后造成查询类交易响应时间变慢的风险，建议添加有关数据库SQL和索引 |