记一次超大规模财务共享平台的性能分析复盘 ——某大型企业共享应用系统功能性能分析
为了响应国家关于《中华人民共和国国民经济和社会发展第十四个五年规划和2035年远景目标纲要》以及国资委提出的《关于加快推进国有企业数字化转型工作的通知》等要求，并适应当前日新月异的国内外经济环境和经济形势，企业集团均需要通过全面、安全、高效的信息化手段，促进企业数字化转型，由高速度增长迈向高质量增长。
大型企业集团的信息化系统具有规模庞大、外部链接多、结构复杂、目标多样、影响因素众多等特点，对于信息化系统、尤其对于全员应用的事务密集型应用系统，其高并发、高可靠性、高兼容性、高可扩展性等方面的要求越来越高。
为了保证这些超大规模信息系统能够持续稳定且高效的运行，需要有良好的运行监控机制以及应急预案，一旦遇到性能卡顿等问题，需要及时排查、即刻解决，这对如此超大规模信息系统的运维团队提出了巨大的挑战。
一、方法论
久其软件多年来在财务共享、合并报表、全面预算、管理会计、综合统计、大数据分析等众多超大规模信息系统运营过程中，积累了大量性能分析与优化经验，包括应用程序、数据库、网络、硬件等多方面的性能分析手段与优化成果。
性能分析首先要了解清楚应用系统现状，根据不同的性能状况针对性结合监控日志进行定向分析。一般从应用自身、数据库、网络、硬件四个大方面进行分析，分析内容如下图所示：
例如，久其软件在分析解决某大型企业财务共享平台功能操作性能问题时，发现其出现的场景相对“冷门”，正是由于这种场景不是很常见，所以整个问题解决历程比较曲折。因此，该案例分析过程和解决手段具有一定的参考价值，在此与大家分享一下这个“冷门”场景的分析过程，做一次性能分析深度复盘。
二、复盘场景
1. 背景
该大型企业有多业务板块且各板块业务差异大。财务共享是核心信息化系统，周边各业务系统都与共享集成，集成复杂度高且量大（100多类接口业务集成），整体业务架构比较复杂。
企业组织架构分四级管控（数千个组织），用户体量大，日常在线用户数高。业务应用频度高，数据量在亿级别，而且经常会有大数据量查询、统计以及导入导出等高计算、内存消耗业务操作。
运行和网络环境复杂，其中包括外网前置机、防火墙DMZ、nginx代理、堡垒机等网络软件。
系统运行情况一直都很平稳，近期系统运营小伙伴突然反馈用户操作随机卡顿问题：系统随机功能点，无规律出现操作一会就无响应、刷新网页后功能又能正常操作的问题。
接到问题反馈后，我们第一时间启动性能应急响应流程，介入分析性能监控信息，力争能够快速排查和解决。
2. 问题初探
初步分析一般从线程dump进行着手分析，通过dump发现问题或问题的蛛丝马迹。Dump信息式快照，所以一般需要多个线程文件结合对比分析才能确定问题，dump一般从以下一些指标进行分析：
根据项目上提供的线程dump初步分析，看线程dump中业务操作线程90%都是与数据库交互且持续时间不长，而且都是SocketRead状态。dump文件如下：
初步分析线程都比较正常，那为什么系统还时不时转圈操作无响应呢？
部分线程快照有接口网络请求处于SocketConnect和SocketRead状态，代表正在等待连接或等待返回数据，初步推断可能是数据库或者网络问题，排查方向就重点放在了这两个方面。
3. 结合AWR再探问题
接下来向DBA申请了AWR报告，一般AWR报告重点关注以下指标：
首先看AWR报告基本信息：
可以看到，在240分钟里收集了4次快照，数据库耗时198分钟，从报告中显示系统有128个逻辑CPU，平均每个CPU耗时1.6分钟，CPU利用率只有0.6%（1.6/240）。从总览上看数据库压力较小，应用负载不高。
然后再看SQL ordered by Elapsed Time报告：
通过Elapsed Time per Exec(s)指标可以看出数据库耗时最长的SQL平均执行时间都是毫秒级别的，说明数据库没有执行很慢的SQL。
通过分析上述两个报告，可以确定数据库方面性能良好，没有问题。排除数据库问题后，接下来把问题定位在网络策略或防火墙上。
4. 通过网络探查问题原因
确定方向后，就把焦点放在网络上，网络问题排查常用有以下几个方向：
使用浏览器开发者工具，观察网络请求情况以及控制台输出情况。发现在应用系统转圈时浏览器控制台有504网关错误以及Network网络请求也是失败的请求连接（504 Gateway Time-Out），如下图所示：
为了进一步确认详细原因，通过开启nginx的debug日志，可以看到客户端向nginx发了请求，但是向应用发请求超时（无法判断请求超时，还是返回超时）。
为了确认网络请求链路使用网络抓包工具对nginx向应用服务器网络端进行了抓包，使用端口进行过滤查看，可以看到端口54659—>80网络流量请求详情如下图：
发现54659端口一直没有返回的请求，序号2100、2965是nginx向服务器发起的重连请求，也没有握手反馈请求，间隔9S。
由此可判断有两种可能：
nginx的请求没发出去；
应用服务器请求没返回来。
通过分析nginx到应用服务器的抓包日志，该54659端口没请求返回，可以使用该端口条件进行过滤看是否接到该端口的请求，通过过滤几个抓包日志都没有请求，如下图：
通过以上分析说明应用服务器没有收到nginx转发请求，可能是被某些软件设备或网络安全策略给拦截掉，所以应用没接到请求，最终超时，导致前端报504网关超时错误。
5. 问题原因论证
定位原因后，联系客户IT部门网络管理员进行测试验证，测试验证场景如下：
nginx配置XX.XX.201.86（转换后的应用服务IP地址），请求过防火墙，频繁点击功能会出现丢包现象。
nginx配置XX.XX.196.86（应用服务器实际IP地址），使用196.86网段客户端请求应用，同网段访问且不通过防火墙，频繁点击服务多次，未出现丢包现象，客户端也不转圈
nginx重新配置为XX.XX.201.86，再次验证，很快能重现丢包和转圈现象
最终确认为防火墙问题，了解到随机卡顿出现前客户网络安全方面更换了防火墙软件厂商，重做了服务器源和目标地址防火墙NAT策略（网络地址转换），导致请求经过防火墙时会被随机拦截，浏览器客户端现象就是功能转圈或无响应。
6. 处理方法和后续策略
根据问题分析报告，和客户IT部门共同评估确定了快速修复处理方案，并安排了后续策略调整及防范机制。
在nginx配置转发地址为应用服务器实际IP地址进行解决（临时使用）；
调整防火墙安全策略；
网络安全策略运维对相关应用的影响评估机制，避免类似问题再发生。
通过复盘过程可以看出引发性能问题的原因是多种多样的，防火墙问题只是超大规模应用遇到各种复杂问题的一种场景。
随着IT技术和企业IT环境不断发展，云原生架构，私有云、混合云对性能问题带来了更大挑战。前后端分离开发模式的应用，对于性能分析的排查步骤和排查方向有所不同，前端性能也是重点分析的方向以及浏览器开发者工具对分析前端性能起到很大作用。
万变不离其宗，性能问题都是从应用自身、服务器资源、数据库、网络几大方面入手分析。夯实基础技术知识、灵活运用工具、大胆猜测、细心论证。久其软件是一家专注于政企信息化建设、数字化转型与智能化升级的管理软件供应商，久其技术团队在服务客户的实际问题上，始终坚持对钻石品质的不懈追求，做“钻石服务”的践行者。
