我的共享点 CSS 有一个奇怪的情况。
它作为 .wsp 解决方案的一部分进行部署,到目前为止一切正常。
它部署的农场也有几个 Web 前端和一个应用程序服务器和 SQL 框。
症状是,如果我部署解决方案,然后使用网络浏览器查看没有样式的页面,如果我直接访问 .css,我会看到 .css 的前 100 个左右的字节。
但是,如果我进入 Sharepoint 设计器并查看文件,它看起来很好,如果我检查并发布它(自定义文件但实际上没有更改其中的任何内容),那么网站工作正常并且 css 下载完全。
服务器上有一些相当复杂的缓存基于磁盘和对象缓存。据我所知,我已经清除了这些(无论如何 issreset 应该清除它们……不是吗?)
我已经使用这个工具清除了整个服务器场的 blobcache http://blobcachefarmflush.codeplex.com/
最佳答案
您描述的问题是我以前遇到过的问题。让我分享我所知道的、我怀疑的以及我将如何对您的场景进行故障排除。
首先,听起来您怀疑缓存是潜在的问题来源。对于 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-sound-as-the-flush-comes/
要查看 BLOB 缓存是否是您所看到的行为的一个因素,您可以修改 Web 应用程序的 web.config 并调整文件模式以从中删除 CSS
根据经验,另一种可能性是您看到的不是 BLOB 缓存异常。对我而言,主要观察结果是您观察到对 CSS 样式表的直接请求仅返回前 100 个字节左右。
在 WFE 和您(调用者)之间是否有任何智能网络硬件(即入侵检测硬件或任何可能执行应用程序/第 7 层过滤的硬件)?入侵检测和 IPS 系统是您所看到的许多类型问题的根源,每当我看到您所描述的“古怪”行为时,它们就是我的第一站。对于我的一个客户,我看到一个问题符合您的描述(CSS 和 JS 文件被截断),这是由于具有事件 IPS 的干预 Juniper 防火墙造成的。关闭 IPS(进行测试)会立即解决问题。之后,网络团队向 Juniper 寻求更新以纠正问题,以确保 IPS 可以保持事件状态。
尝试关闭 BLOB 缓存(或从文件模式中删除 CSS 扩展名)以查看是否有所不同。如果没有,请与您的网络团队联系,看看返回给您的响应流是否有问题。那就是我要开始的地方;希望这两件事中的一件能为您解决问题。
小提示:如果您有空闲时间并且愿意,我想听听您对从 CodePlex 提取的 BlobCacheFarmFlush 解决方案的体验。它是我创作的,我很想听听你的想法——好的或坏的 :-)
- 肖恩 (sean@sharepointinterface.com)
关于css - 你能解决我奇怪的 Sharepoint CSS 缓存/自定义问题吗?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1312801/