Azure Files 元数据缓存与本地分支缓存之比较
服务端元数据缓存可减少服务器工作量，但不会把往返从你的 WAN 上移走。请按两者真正缩短的是什么来比较。
针对通过 VPN 访问 Azure Files 缓慢的问题，通常会提出两项改动，而它们缩短的东西并不相同。服务端元数据缓存让符合条件的操作对服务器更便宜；本地分支缓存则把字节和操作搬到离用户更近的地方。凭价格表或新闻稿在两者之间做选择，结果往往是共享在基准测试里变快了，而早上九点依然如故。
两种缓存，两种不同的延迟
两种方案都出现在“缓存”这个词下面，混乱也正是从这里开始的。它们位于网络的两端。
| Change | Where it acts | What it does not imply |
|---|---|---|
| Azure Files service metadata caching | The service's handling of supported metadata operations on eligible shares | No removal of the client's network round trips |
| A supported local server or cache design | Some content and operations placed nearer the users | No universal offline access or instant cross-site consistency |
| Application batching or limited copy concurrency | The number and overlap of remote operations | No automatic speedup for every workload |
Microsoft 的 SMB 性能指南 介绍了符合条件的 SSD 共享的元数据缓存，以及与之配套的注册步骤。是否符合条件、功能处于什么状态，取决于实际的存储账户，因此请阅读当前页面，而不是两年前的预览公告。
把等待拆成三部分
每一次缓慢的目录列举都有三项成本，而它们对应不同的解决办法。一是服务端处理每个请求的时间，二是跨 VPN 的依赖式往返次数，三是必须搬动的数据量。服务端缓存攻击的是第一项；服务器侧没有任何东西能攻击第二项。
这就是为什么共享的服务指标可能更好看，而用户的文件选择框仍然会卡住八秒。
两种方案各自适合什么场景
如果工作负载以元数据为主，对符合条件的 SSD 共享有大量打开、stat 调用和目录枚举，那么服务端缓存是便宜的实验。它不需要新基础设施，也不改变用户访问共享的方式。
如果工作负载是交互式的、受延迟约束，那么诚实的选项是受支持、且有明确同步模型的本地服务器方案。那是另一种架构，有自己的运行成本，而不是一个开关。
两种方案都改变不了的事
SMB 签名和加密仍然生效，该花多少还是多少。访问控制仍按用户逐个解析，所以缓存副本并不会简化授权。站点之间的一致性仍然需要明确的模型，因为分支本地读取和云端写入必须就某件事达成一致。而离线访问始终是客户端设置，不是服务器功能的副作用。
当有人承诺某项服务功能能消除 WAN 往返时，那正是最该先验证的说法。
针对用户抱怨的那个操作去测量
测量确切的操作，而不是合成副本。在分支客户端上运行 Measure-Command { Get-ChildItem \\files\projects -Recurse }，可以得到前后可比的数字；Get-SmbMultichannelConnection 则显示客户端是否使用了多条路径。把它和同一时间窗口的服务端延迟指标放在一起看。
保持共享、客户端位置、VPN 路径和安全策略不变，否则你测的是自己的变更窗口，而不是这项功能。还要记录文件数量和大小分布，因为小文件负载和大批量复制响应的是完全不同的杠杆。
真正值得要的结果，是与实际变慢的那条边界相匹配的改动，并写清它的运行成本和一致性成本。幻灯片上更大的存储 IOPS 数字并不是那个结果。