如何评估和调查应用性能问题？
推荐阅读
技术决策者 | 项目经理 | 高级技术人员 | 初级技术人员 | 测试人员 |
|---|---|---|---|---|
√ | √ | √ |
type=info
性能的检测与评估是一项专业性强、时间投入大的工作。我们建议合理安排人力投入，在费效比上找到均衡点。
一、开发阶段：排查性能风险
在功能开发和测试无误后，推荐您进行性能测试，在第一时间进行处理，避免为系统引入性能风险。测试可以分为单并发的理论性能测试和并发请求下的压力测试两种。
1.1 理论性能测试
服务器的处理性能和并发请求数量直接相关。为了快速建立可纵向对比的性能“基线”，推荐开发者为并发量不高的企业软件做单并发的理论性能测试。理论性能测试通常是性能调优的一部分，推荐采用活字格的日志功能记录被测试服务端命令的执行情况和耗时，为调优工作做好准备。对于采用 RPC架构（前后端分离）的应用，推荐的做法如下：
将应用发布到测试服务器，修改连接字符串到测试用数据，把生产环境的数据库还原到测试用的数据库（不要在正常使用的生产环境的应用服务器或数据库服务器上做任何的性能测试）
在管理控制台上【设置】→【日志】菜单中【日志设置】选项卡，启用测试应用的日志功能，需确保启用“服务端命令日志”
确保没有其他用户使用测试服务器
使用浏览器打开测试应用，操作新开发或调整的功能，覆盖该功能的全部场景
在管理控制台上【设置】→【日志】菜单中【历史日志】选项卡，选择测试应用后点击【查询】按钮，在结果中点击【日志类型】右侧的箭头，筛选“服务端命令日志”，依次点击本次开发的服务端日志对应的日志行右侧的【详情】，在【执行日志】项目中查看其“用时”，如果长于预期，需要做“问题调查”。
1.2 压力测试
压力测试的专业性较强，通常由测试团队或掌握相关技能的开发者执行。对于部署在公有云的应用，推荐采用压力测试的云服务来设计和执行测试，如 阿里云的性能测试PTS；如果服务器部署在局域网，则推荐采用JMeter作为压力测试的工具，具体操作方法请参考测试工具的文档。
再次强调：不要在正常使用的生产环境的应用服务器或数据库服务器上做任何的性能测试
在测试非匿名方法前，需要先通过OAuth2认证接口获取token，并且添加到测试请求的标头中，但不要把获取认证的调用纳入压力测试范围。具体做法参考：用服务端命令开发和调用WebAPI，实现服务器间数据通讯
1.3 问题调查
当遇到某个页面加载速度慢，或点击按钮后响应速度不及预期时，推荐您使用浏览器内置的调试工具等相关工具来进行追踪，分别看数据库操作、服务端逻辑处理、网络传输和页面渲染花费的时间，快速确定问题所在。
这部分工作的差异化程度高，涉及的知识面较广，导致开发者的经验会显著影响调查效率。强烈推荐由团队内资深的开发者负责性能问题调查。推荐阅读：性能诊断与优化示例
层 | 工具 | 常见的性能风险 |
|---|---|---|
数据库操作 | SQL Profiler | 无索引（索引碎片高）、不必要的JOIN |
服务端业务逻辑 | Chrome DevTools：Network选项卡中选择WebAPI（xhr）后点击Timing选项卡，TTFB约等于于服务器业务逻辑处理耗时 | 循环嵌套 |
网络数据传输 | Chrome DevTools：Network选项卡中选择页面、资源或WebAPI（xhr）后点击Timing选项卡，Download就是传输耗时 | 没有设置CDN、网络带宽低、传输的数据中存在无用数据 |
页面渲染 | Chrome DevTools：Performance选项卡中点击录制，记录页面加载或交互过程，在录制结果中点击Summary选项卡，Rendering和Painting是渲染耗时 | 页面中包含的元素太多 |
二、使用阶段：关注性能变化
2.1 用户体验优先，先看平均响应时间
“本来没有性能问题，除非用户觉得慢。”
现实生活中，软件系统的性能是一个偏主观的指标。性能是否合格，首先要看用户体验的期望是否得到满足。对于企业软件来说，服务端的业务处理对性能带来的影响远高于页面的静态资源加载（尤其是启用了CDN后）。所以，服务器响应速度比浏览器速度更受关注。在实践中为了排除干扰、定位性能问题，人们通常会关注单个WebAPI（如果一个WebAPI内会根据不同的URL参数或Body参数执行不同的逻辑，建议分别进行统计，以确保数据的准确性），即评估每一个WebAPI的响应速度。
具体操作方法可使用ELK方案对生产环境中nGinx的日志进行分析，URL路径中包含ServerCommand的就是服务端命令请求。详细了解：如何设计生产环境的部署方案？
实际项目中，在系统上线后一切正常的情况下，无需实时关注性能变化，推荐在以下节点集中力量分析性能指标并作出应对：
新系统试运行到功能稳定时，判断平均响应时间是否符合预期
加入新功能模块并发布后一段时间（推荐为1周），判断平均响应时间是否符合预期
对功能模块进行“大改版”后一段时间（推荐为1个月），与该功能模块发布时的测试数据进行对比，避免出现性能劣化
系统维护一段时间后（如每年），与前一阶段进行对比，及时发现和应对性能劣化
2.2 兼顾成本优化，关注资源占用率
进入云计算时代，资源占用率需重点关注成本可变的项目，即CPU占用率、内存占用率和网络带宽占用率。资源占用率持续走低时，可以考虑通过缩减计算资源或带宽来节约运维成本；如果占用率持续偏高，为了确保响应时间不会因为预期外的请求拖累，可提前提升计算资源或带宽。
在对计算资源进行扩容前，建议参照最佳实践自查，排除性能隐患
推荐综合评估对系统进行性能优化工作花费的人力成本和计算资源扩容带来的运行成本
如果单节点（应用服务器+数据库）无法满足要求，推荐切换为集群部署模式，详情请见：生产环境的部署方案 中 私有化部署→集群部署 章节
type=info
温馨提示
企业级低代码开发最佳实践是活字格官方面向进阶开发者推出的产品技术资源，旨在帮助对活字格基本功能有一定了解的开发者快速提升应用开发能力，保质保量做好企业级项目交付。如果您是初次接触活字格，这些内容可能会有些艰深难懂，这也是正常的。如果您有软件开发经验，推荐您学习《面向程序员的活字格入门课程》；否则，您也可以免费报名参加新手训练营直播课程或购买阅读《低代码开发实战：基于低代码平台构建企业级应用》（机械工业出版社），快速上手低代码开发。