有人可以解释Google Chrome内存中缓存吗？ [英] Can someone explain Google Chrome in-memory cache?
问题描述
根据这个 API文档，这是我发现的唯一来源，它描述了内存缓存：
Chrome采用两个缓存 - 一个磁盘缓存和一个非常快速的内存
缓存。内存中缓存的生命周期被附加到渲染进程的生命周期
，这大致对应于一个制表符。请求从内存缓存中回答
的请求对于Web请求
API不可见。如果请求处理程序改变其行为（例如，根据哪些请求被阻止，
行为），简单页面
刷新可能不会遵守这种改变的行为。为了确保
行为更改通过，调用handlerBehaviorChanged（）以刷新内存缓存中的
。但不要经常这样做;刷新缓存是非常昂贵的
操作。在注册或取消注册事件
侦听器后，您不需要调用
handlerBehaviorChanged（）。
I需要更好地理解内存缓存。具体来说，我需要Chrome每次访问网站时生成完整的WebRequest /资源瀑布，包括刷新页面。显然，如果它使用内存中的缓存，这是不正确的。
当我创建一个新选项卡时，内存缓存对于新选项卡是干净的吗？ ？
什么是非常昂贵的操作在数量上是指？
如果每次页面调用handlerBehaviorChanged重新加载在同一个标签中，这将保证完整的瀑布？在这种情况下，超过10分钟20次的限制似乎相当低。
任何帮助都非常感谢，谢谢！
在您的情况下，我认为您的问题是使用长期缓存而不是内存缓存。在资源瀑布中，几个请求可以被标记为缓存。如果您想要避免这种情况，可以采取多种方式：
<请记住只将这些规则应用于您真正需要的资源。否则，您的网络服务器将被重载请求。
如文件中所述：即使对于相同的url和in，内存中缓存也不适用于不同的页面渲染同一个标签（内存中的缓存被附加到渲染进程的生命周期中），所以我认为这不适用于你的情况。每次页面显示时渲染周期结束，如果再次渲染，则渲染周期结束。例如：第一次加载图片时出现在瀑布中，但是在同一页面上没有以后的请求。
According to this API doc, which is the only source I've found which describes the in-memory cache:
Chrome employs two caches — an on-disk cache and a very fast in-memory cache. The lifetime of an in-memory cache is attached to the lifetime of a render process, which roughly corresponds to a tab. Requests that are answered from the in-memory cache are invisible to the web request API. If a request handler changes its behavior (for example, the behavior according to which requests are blocked), a simple page refresh might not respect this changed behavior. To make sure the behavior change goes through, call handlerBehaviorChanged() to flush the in-memory cache. But don't do it often; flushing the cache is a very expensive operation. You don't need to call handlerBehaviorChanged() after registering or unregistering an event listener.
I need a better understanding of the in-memory cache. Specifically, I need Chrome to generate the full webRequest / resource waterfall every time I visit a site, including refreshing a page. Obviously, this can't be true if it's using an in-memory cache.
Is the memory cache a clean-slate for a new tab when I create a new tab?
What does "very expensive operation" mean quantitatively?
If I call handlerBehaviorChanged() every time a page is reloaded in the same tab, will that guarantee a full waterfall? In that case, a limit of 20 times over 10 minutes seems fairly low.
Any help is highly appreciated, thanks!
In your case I think that your problem is with the long term cache instead the in-memory cache. In the resource waterfall several requests can be marked as cached. There are various manners to avoid that if you want:
- Instead of normal reloading (F5) press CTRL+F5. That will reload all the resources, I usually press CTRL+F5 several times although one time must be suficient.
- If you need that your page reload some specific resources from server each time any user visit you then you can use some of this techniques:
- The most elegant: configure your server to return cache policies in the HTTP headers https://developer.mozilla.org/es/docs/Web/HTTP/Headers/Cache-Control
- Add to your request a changing get parameter different each time, for example use milliseconds. For example: https://www.gravatar.com/avatar/c6252fcbc3ce5fc144c11dedd75bce29?_=1501147200802 where 1501147200802 is different for each reload. This will confuse cache so resource will be loaded from server each time you request it.
Remember to apply these rules only for the resources that you really need to. Otherwise your webserver will be overloaded with innecesary requests.
As stated in the document mentioned: in-memory cache does not apply to different page renderings even for the same url and in the same tab (in-memory cache is attached to the lifetime of a render process), so I think that does not apply for your case. Rendering cycle ends each time the page is displayed and a different one starts if rendered again. For example: when a image is loaded for the first time appears in the waterfall, but no for later requests on the same page.
这篇关于有人可以解释Google Chrome内存中缓存吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
