标签：磁盘io 避免 upload ati alt 文章 话题 系统 response
在Jerry的其他文章曾经提到，Salesforce里运行时对象均是通过静态存储的元数据，经过Runtime engine加工而成的。
Because metadata is a key ingredient of Force.com applications, the system’s runtime engine must optimize access to metadata; otherwise, frequent metadata access would prevent the service from scaling.
既然元数据在salesforce平台中扮演了如此重要的角色，那么运行时引擎对元数据的高效访问就成为一个重中之重的话题，如果达不到这个目标，频繁的元数据低效访问将无法保证平台上提供服务的高扩展性 high scalability。
With this potential bottleneck in mind, Force.com uses massive and sophisticated metadata caches to maintain the most recently used metadata in memory, avoid performance-sapping disk I/O and code recompilations, and improve application response times.
Salesforce平台设计了很多复杂的元数据缓存机制，确保最近访问过的元数据驻留在内存里，避免了磁盘IO的开销和代码的重编译，从而确保整个应用的响应时间不会影响元数据访问受到影响。
ABAP Netweaver也有类似的设计，把很多需要高效访问的数据特别是应用程序的元数据存储到应用服务器的shared memory共享内存里。
使用事务码SHMM查看shared memory内容：
SAP HANA里还能通过系统视图system view M_METADATA_CACHE_STATISTICS来对元数据的缓存访问进行分析：
要获取更多Jerry的原创文章，请关注公众号"汪子熙":
标签：磁盘io 避免 upload ati alt 文章 话题 系统 response
原文地址：https://www.cnblogs.com/sap-jerry/p/10381194.html
