做 SAP Fiori 或外部系统集成时，有一种性能问题非常容易被忽略。页面只展示几块数据，看起来业务逻辑并不复杂，浏览器的 Network 面板里却同时出现五六个甚至十几个 OData 请求。每个请求返回的数据可能只有几 KB，但页面仍然感觉迟钝。
问题往往并不在 ABAP SQL，也不一定在 SAP HANA，而是在客户端与 SAP Gateway 之间进行了过多次 HTTP 往返。
SAP 对这类场景给出的建议其实非常明确。对于彼此没有 Association 关系的 Entity Type，如果客户端需要执行多个请求，应考虑通过$batch把多个逻辑请求封装进一个 HTTP 请求。只有两个独立的 Read，或者两个属于不同原子工作单元的 Update 时，可以考虑并行调用，也可以采用$batch。一旦独立请求数量超过两个，SAP 的性能建议更偏向$batch，核心目的就是避免客户端与 SAP Gateway Server 之间产生过多 Roundtrip。
这条建议看上去只有几句话，但里面其实藏着 SAP OData 性能设计中几个非常重要的判断维度，包括 Association、Roundtrip、Parallel Call、Batch、Change Set、Atomic Unit of Work、LUW，以及网络延迟和后端执行时间之间的关系。
很多 OData 性能问题，真正困难的地方并不是知道$batch存在，而是知道什么时候该用它，什么时候不该用它。
我们从最常见的 Fiori 页面说起。
假定一个 SAP S/4HANA 应用首页需要显示销售
