一、 总述
作为一个项目来说，最担心一个问题就是出现性能问题，性能问题因为比较复杂，不好定位，影响因素很多，如何快速定位和排查是大家比较关心的问题，性能问题主要体现为整体系统卡顿、数据列表加载缓慢等问题，登录系统慢等，也有可能会出现局部出现卡顿，如某个单据打开慢、点击按钮操作慢等，还有线上出现异常问题，系统闪退问题等，对于很多开发人员来说可能都会有这种苦恼，在开发环境没法复现，在生产环境又没办法调试等等，诸如此类的生产环境问题我们应该如何排查分析呢？这篇文章就结合实际项目众多性能问题案例来解析如何排查和分析定位性能问题，希望能给大家提供更多的思路，当遇到性能知道从哪些方面去排查，并且帮助大家在实际项目中规避一些可能会产生的性能问题。
二、 遇到性能问题的项目案例
场景1：第三方工具扫描影响
1. 现象描述：
生产环境刚上线，现象为特别卡，特别是财务初始化环节，上线前几天测试环境还不卡，可生产环境刚上线，这一天是周六，现象截图如下：
提示信息为“正在终止线程”
1. 原因分析和排查：
1） 从网络方面排查，没问题
2） 从服务器上直接访问没问题，速度不慢，
3） 是大面积卡，也不是某台电脑卡。
4） 从系统日志看和windows的日志来看，也没发现什么程序影响到性能
5） 从是否有第三方工具扫描等其他因素排查，结果发现集团在全国城域网内有定时扫描任务，影响到了系统使用
2. 结论：
1） 本次影响到系统慢，卡顿的原因则是集团定时扫描安全及漏洞等。对星空使用构成了影响，说明服务器扫描时会消耗大量的性能，造成对使用中的星空软件能构成很大的影响
2） 在排查性能影响是第三方软件也是一个重点排查项
案例2：部署+代码排查
1. 现象描述：
有一客户，现场10.25反馈出现全面系统卡顿，大面积登录超时，从下午3点、晚上9点监控应用服务器结果，存在TCP连接数高、端口释放不及时的情况，导致网络连接很慢（局域网ping延时可达3667ms）。其中mysqld.exe、java.exe程序占了连接数的主要部分
2. 原因分析：
1） 从mysqld.exe、java.exe，这两个占用连接数最高的进程来分析，发现这些进程来自集成平台这边
2） 发现出现这种情况是因为这时间段大量的第三方财务软件系统正在大批量的同步凭证到星空平台
3） 从集成平台部署的方式及现有星空的部署方式上进行分析，目前是将集成平台、管理中心、星空应用服务器部署在一起了，对性能一定会造成影响
4） 从集成平台调用星空接口的实现方式上进行了排查，发现调接口完成后没及时释放连接，如果同步数据量很大，则星空就会存在大量的未释放的连接数，当连接数达到极限后则应用服务器会停止工作。
3. 结论：
1） 系统集成时一定要考虑集成时对星空系统的影响，要考虑集成时请求服务器的频率及数据量的的大小，尽量减少与星空的连接请求，方法是部署时不能将第三方的系统跟星空应用服务器放在一起，分开部署
2） 集成代码实现上尽量使用批量接口，如果星空接口有些业务复杂，写入时需要校验，则可以考虑先放写入中间表，然后再在空闲时间短用事务批量调接口写入，批量可以减少连接数，并且批量写入本身也是提升性能的一种方式
3） 代码上在调用接口完成后需要及时释放连接，防止太多的连接对星空系统造成影响
案例3：代码实现排查
1. 现象描述：
1） 项目1：
一家国产化替代项目，在未上线前的测试环境，有一天，突然出现PDA在扫码入库操作后，造成整个系统都会闪退，
2） 项目2：
一家国内集成软件使用了星空产品，二开由一家伙伴完成，二开写了一个导入功能时会特别慢，数据量稍微一大就会超时
3） 项目3：
原来使用CAPP工艺管理软件，后面换做购买星空PLM模块，并在上面基于星空平台开发一个具有原来CAPP工艺管理软件的各项功能，其中有一个批量工艺计算特别耗费性能，代码里实现时使用了多线程进行处理，发现工艺计算并行量一大时就会特别慢，并且耗费时间特别长。
2. 原因分析：
1） 对于上面项目1出现的情况分析，最开始找原因时从应用服务器日志看确定是有IIS重启了，确定肯定是某个程序实现出问题了，后面从负责测试的实施人员中了解到，是PDA在进行某个扫码入库时触发的整体系统出现闪退。
2） 开发人员从这个功能最近部署情况了解到，前一天下班时部署了一个二开功能，然后从代码分析是在保存方法里写了一段代码调用某个操作时会存在死循环调用的情况，PDA调用的是保存操作会触发二开插件，造成死循环，造成这边一扫码则IIS会奔溃，并重启。
案例4：本可以使用星空套打，利用万能报表打印
1. 现象描述：
一家星空企业版客户，是公司的战略客户，由于系统使用久了，版本是7.1版本，
所以当时最突出的问题就是性能问题，尽快很多地方比如算成本等都做过优化，但
后面发现最突出的性能问题就是打印的性能问题，当初客户反馈最严重最突出的打
印慢的是计划汇报单，使用频率高，还特别慢。
2. 原因分析：
（1） 通过分析发现慢的原因不是使用套打模板在打印，是使用的万能报表在打印，为什么大量的使用万能报表进行打印呢？据了解当初是因为某些场景实现不了，然后用万能报表能实现，后面很多报表都改成万能报表了
（2） 总部负责套打这块的老师分析了一下计划汇报单这个特殊场景，实际上是可以实现和满足的，完全都可以通过配置来实现，通过总部老师支持后，最后改为了套打模板来实现，打印预览的时间由原来的1分钟变为了1-2秒，效率提高了几十倍，后面其他用万能报表做的打印慢的都改为套打来实现了。
3. 结论：
（1） 能用套打来实现的尽量不要用万能报表，因为万能报表用了很多第三方组件，加载的时候性能没那么好，所以选择方案时一定要考虑这个性能因素
（2） 如果套打遇到问题时可以咨询总部负责这块的专业老师来协助，不能自作主张更换实现方式
案例5：管理中心有多个账套时有未连接不上数据库的账套时
1. 现象描述：
星空首家拆分项目上线时，当初旧账套未反注册，只是数据库连接断开
了（开始是为了如果拆分账套出现意外时能快速切换到原来就账套使用），用，结果拆分项目刚上线的第一天，出现大面积登录时特别慢，并且甚至用户一多时特别慢
2. 原因分析：
（1） 总部平台负责这块的老师排查时首先从管理中心下手，打开管理中心看目前有多少个账套，每个账套测试一下是否都是通的，结果发现其中一个旧账套不通。
（2） 初步定位应该是这个原因引起的，然后就将这个账套反注册，然后再观察，后面登录也变为正常，用户并发数很高时也再没出现访问特别慢的情况。
3. 结论：
管理中心登录首先要加载数据中心，如果存在连接不上的数据库的账套，系统尝试连接的过程会比较好性能，所以需要注意当存在多数据中心，一定不要存在连接不上的数据中心，否则并发用户量很大时会对系统造成重大的影响，会消耗大量的性能。
三、 遇到性能问题时排查方法
1. 服务器配置排查
（1） 检查应用服务器是否存在瓶颈（包括CPU、内存、硬盘），是否存在并发瓶颈，检查和监控应用服务器的应用情况，是否存在瓶颈
（2） 检查数据库服务器是否存在瓶颈（包括CPU、内存、硬盘），检查数据库服务器是否为物理机，是否硬盘存在读写问题，建议做好用固定硬盘
（3） 如果应用服务器有做集群，检查集群服务器每个的使用情况，是否有很好的做负载均衡。如果负载均衡做得不好，也会影响性能的。
（4） 数据库如果做RAC的话，需要关注每台数据库服务器的使用情况，如果有一台出现CPU或者内存持续接近100%时，整体系统性能肯定会受到严重影响，需要找原因。
2. 网络排查
（1） 检查网络端口使用情况，可以ping一下这些端口使用情况
（2） 通过TCP连接分析，检查网络延迟情况，是否存在大量网络阻塞的情况
3. 服务器日志排查
（1） 检查应用服务器日志是否存在重大错误，包括IIS重启等日志信息，帮助分析，因为有些组件的兼容问题或者代码存在重大性能问题时，这边服务器日志都可以监控得到
（2） 数据库服务器也可以定期检查一下，还可以定期检查数据库本身的日志
4. 系统集成部署方案排查
（1） 集成部署方案不合理会造成大量请求时可能会造成应用服务器奔溃，部署时需考虑将第三方系统跟星空的管理中心和应用服务器分开，如果应用服务器多台集群时，可以考虑集成时指向某台服务器，减少对整体性能造成莹
（2） 第三方对接星空时，一定要注意及时释放连接，代码实现时一定要注意
（3） 系统集成时尽量使用批量的方式，减少连接，提高系统的性能
5. 星空产品本身的排查
（1） 星空企业版可以利用APM性能监控工具，具体操作请见指引
https://vip.kingdee.com/article/184271?productLineId=1&isKnowledge=2
（2） 如果是WEB API，也可以利用APM进行监控，到底是哪些地方耗时比较长，具体参考地址如下：
https://vip.kingdee.com/link/s/lHLm1
https://vip.kingdee.com/link/s/ldCM2
（3） 如果是无法识别是标准插件还是二开插件引起的，可以先通过协同开发平台签出修改，将二开插件去掉排查性能的提升情况，用排除法去逐渐识别性能瓶颈，注意排查完后不要签入，点回滚就行
（4） 如果是页面加载的字段太多，或者是有大字段太多，也可以删掉不必要的大字段，界面不需要的字段可以删点，防止对系统加载构成性能影响
（5） 对二开代码进行分析，看代码中是否有影响性能的代码出现
（6） 通过星空的日志文件去排查，看日志文件是否有大量报错，如果大量异常报错也会影响性能
6. 个人电脑排查
（1） 如果是用户的个别电脑慢的话，可以排查用户的个人电脑配置，检查是不是个人电脑配置太差，或者是使用的网段本身访问服务器就比较慢
（2） 检查个人电脑的网络访问速度
推荐阅读