Loo*_*fer 3 css sharepoint caching solution
我的sharepoint css有一个奇怪的情况.
它被部署为.wsp解决方案的一部分,直到现在一切都很好.
它部署的服务器场也有几个Webfront端和一个应用服务器和SQL框.
症状是,如果我部署的解决方案,然后使用一个网页浏览器来查看它有没有风格的页面,如果我直接访问的CSS我看到的第一个100左右个字节的CSS的.
但是,如果我去到SharePoint Designer中,看看它是文件看起来很好,如果我检查出来,并发布(自定义文件,但它实际上没有任何变化),那么该网站正常工作和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-作为最冲洗配备/
要查看BLOB缓存是否是您所看到的行为的一个因素,您可以修改Web应用程序的web.config并调整文件模式以从<BlobCache>中的文件类型列表中删除CSS元素,然后重新启动IIS(或至少回收应用程序池).
根据经验,另一种可能性是你看到的不是BLOB缓存异常.对我来说,关键的观察结果是你观察到CSS样式表的直接请求只返回前100个字节左右.
您是否有任何机会在WFE和您(呼叫者)之间拥有任何智能网络硬件(即入侵检测硬件或可能正在执行应用程序/第7层过滤的任何东西)？入侵检测和IPS系统是您所看到的许多类型问题的根源,只要我看到您所描述的"古怪"行为,它们就是我的第一站.对于我的一个客户,由于具有活动IPS的干扰Juniper防火墙,我看到了满足您的描述(CSS和JS文件被截断)的问题.关闭IPS(测试)立即清理.之后,网络团队寻求Juniper的更新来纠正问题,以确保IPS能够保持活跃状态.
尝试关闭BLOB缓存(或从文件模式中删除CSS扩展),看看是否有所作为.如果没有,请与您的网络团队联系,以了解回复给您的响应流是否发生了什么.那是我开始的地方; 希望,这两件事中的一件可以帮到你.
小方面注意事项:如果您有空闲时间并且愿意接受它,我想了解您从CodePlex下载的BlobCacheFarmFlush解决方案的体验.我写了它,我很乐意听到你的想法 - 好的或坏的:-)