在使用新的捆绑和缩小功能对 ASP.NET 应用程序中的性能问题进行故障排除时,我注意到访问捆绑中使用的 javascript 文件的大量文件活动。
在对一个干净的 MVC 应用程序进行一些测试之后,我注意到在第一个请求之后,我希望它读取文件以构建捆绑包,但它在大约一分钟左右的时间里没有读取后续请求的文件. 然后它会再次读取它们,然后再安静一分钟左右。
显然这里有某种缓存,但是捆绑内容在哪里被缓存以及缓存了多长时间?我可以通过配置来控制那段时间吗?
在使用新的捆绑和缩小功能对 ASP.NET 应用程序中的性能问题进行故障排除时,我注意到访问捆绑中使用的 javascript 文件的大量文件活动。
在对一个干净的 MVC 应用程序进行一些测试之后,我注意到在第一个请求之后,我希望它读取文件以构建捆绑包,但它在大约一分钟左右的时间里没有读取后续请求的文件. 然后它会再次读取它们,然后再安静一分钟左右。
显然这里有某种缓存,但是捆绑内容在哪里被缓存以及缓存了多长时间?我可以通过配置来控制那段时间吗?
响应缓存在 HttpContext.Cache 中,通过调用 Insert 并针对用于生成包的文件的 VirtualPathProvider 设置 CacheDepedency。
/// <summary>
/// Stores the response for the bundle in the cache, also sets up cache depedencies for the virtual files
/// used for the response
/// </summary>
public void Put(BundleContext context, Bundle bundle, BundleResponse response) {
List<string> paths = new List<string>();
paths.AddRange(response.Files.Select(f => f.VirtualFile.VirtualPath));
paths.AddRange(context.CacheDependencyDirectories);
string cacheKey = bundle.GetCacheKey(context);
CacheDependency dep = context.VirtualPathProvider.GetCacheDependency(context.BundleVirtualPath, paths, DateTime.UtcNow);
context.HttpContext.Cache.Insert(cacheKey, response, dep);
bundle.CacheKeys.Add(cacheKey);
}
原来我使用的是整个 MVC4 堆栈的预发布版本,包括 System.Web.Optimization。升级到 RTM 解决了这个问题。