您描述的问题是我以前遇到的问题。让我分享我所知道的、我怀疑的以及我将如何解决您的场景。
首先,听起来您怀疑缓存是潜在的问题来源。在 MOSS 发布功能集的情况下,您确实有三种不同的缓存机制在运行:对象缓存、BLOB 缓存和页面输出缓存。唯一应该起作用的机制是 BLOB 缓存,假设它是使用默认设置打开的。对象缓存和页面输出缓存都不应该像您那样接触独立的样式表。
您已尝试使用场级 BLOB 缓存刷新功能刷新缓存,这将指示 MOSS 转储所有 BLOB 缓存数据。您可以通过检查文件系统来验证这一点,以确保在刷新后仅保留三个 .bin 文件夹。
对于您关于 IISRESET 的具体问题:不,并且 IISRESET 实际上不会清除 BLOB 缓存。BLOB 缓存的内容会在为 Web 应用程序提供服务的应用程序池的生命周期内持续存在。您要么需要使用一项功能来清除缓存(就像您一样),要么执行手动文件删除。我不推荐后者,除非您绝对没有其他行动方案。如果您选择手动尝试,请确保在从文件系统中删除文件之前关闭 W3SVC 服务。如果不这样做,实际的文件删除过程可能会进入缓存重新填充的竞争状态并导致损坏。使用停止的 W3SVC 删除文件后,您可以再次启动 W3SVC 备份。
有关 BLOB 缓存的内部结构及其运行方式的更多信息,请参阅我的一篇博客文章:http: //sharepointinterface.com/2009/06/18/we-drift-deeper-into-the -如潮水般的声音来了/
要查看 BLOB 缓存是否是您所看到的行为的一个因素,您可以修改 Web 应用程序的 web.config 并调整文件模式以从<BlobCache>中的文件类型列表中删除CSS元素,然后重新启动 IIS(或至少回收应用程序池)。
根据经验,另一种可能性是您看到的不是 BLOB 缓存异常。对我而言,关键的观察来自于您观察到对 CSS 样式表的直接请求仅返回前 100 个字节左右。
您是否有任何智能网络硬件(即入侵检测硬件或任何可能执行应用程序/第 7 层过滤的东西)在 WFE 和您(呼叫者)之间?入侵检测和 IPS 系统是您看到的许多类型问题的根源,每当我看到您所描述的“古怪”行为时,它们都是我的第一站。在我的一个客户的案例中,我看到了一个符合您的描述的问题(CSS 和 JS 文件被截断),因为介入的瞻博网络防火墙具有活动 IPS。关闭 IPS(测试)立即清除了一切。之后,网络团队向瞻博网络寻求更新以纠正该问题,以确保 IPS 可以保持活跃。
尝试关闭 BLOB 缓存(或从文件模式中删除 CSS 扩展名),看看是否会有所不同。如果没有,请与您的网络团队联系,查看返回给您的响应流是否发生了问题。那就是我要开始的地方;希望这两件事中的一件可以为您解决问题。
小旁注:如果您有空闲时间并且愿意,我想听听您对从 CodePlex 中提取的 BlobCacheFarmFlush 解决方案的体验。我创作了它,我很想听听你的想法——好还是坏:-)
- 肖恩 (sean@sharepointinterface.com)