一个 SAP Fiori 页面突然从两秒变成十二秒，开发团队通常很快会把怀疑对象放到 CDS View、SQL、HANA 执行计划或者 ABAP 业务逻辑上。但在真正进入数据库分析之前，还有一个经常被忽略的问题，我们看到的这十二秒，到底有多少发生在应用代码里，又有多少耗在 SAP Gateway Hub、Backend Framework、RFC 通信和网络传输上。对于经典 SAP Gateway 技术栈而言，/IWFND/TRACES中的 Performance Trace 正是用来回答这个问题的工具。SAP 官方将它定位为服务调用级别的性能分析工具，可以记录 SAP Gateway Hub 与后端系统中的 OData 请求处理过程。Hub 侧通常使用事务码/IWFND/TRACES，Backend 侧则对应/IWBEP/TRACES。这里有一个很重要的理解角度。Performance Trace 并不是另一套 ST05，也不是把 SAT 搬进 Gateway。它关注的是一条 OData 请求穿越 Gateway 技术栈时，各个逻辑区段分别消耗了多少时间。这恰好解决了 SAP Fiori 和 OData 性能排查中最容易出现的责任边界问题。假设我们的销售订单列表应用打开缓慢，浏览器 Network 面板里看到某个 ODataGET请求耗时八秒。仅凭这八秒，并不能直接得出 CDS 查询慢或者 ABAP 代码慢的结论。请求可能在 Gateway Hub 中花掉一部分时间，在 Hub 与 Backend 之间的 RFC 和网络通信上消耗一部分时间，在 Gateway Backend Fra