http缓存问题

发布于 2024-10-03 22:44:02 字数 393 浏览 1 评论 0原文

我有一个从数据库中提取的存储库,有时还从缓存中提取。

为了实现这一点,我创建了一个接口 ICacheWrapper,它允许存储库使用 HttpRuntime.Cache、AppFabric 等。 ICacheWrapper 的具体类通常在其构造函数中获取缓存,如下所示: new HttpCacheWrapper(HttpRuntime.Cache)

存储库的构造函数采用对缓存包装器的引用,如下所示:

myRepo = new Repo(new HttpCacheWrapper(HttpRuntime.Cache));

如果我创建 2 个存储库,缓存是否会被深度复制?我认为不会,但我们的性能问题表明情况并非如此。我在这里错过了什么吗?

感谢您的帮助!

I have a repository that pulls from both db, and sometimes a cache.

To implement this, I created an interface ICacheWrapper that lets the repo use HttpRuntime.Cache, AppFabric, whatever. Concrete classes of the ICacheWrapper usually take the cache in their constructor like so: new HttpCacheWrapper(HttpRuntime.Cache)

The repo's constructor takes a reference to a cache wrapper like so:

myRepo = new Repo(new HttpCacheWrapper(HttpRuntime.Cache));

If I create 2 repos, does the cache get deep copied? I would think not, but our performance problems indicate otherwise. Have I missed something here?

Thanks for any help!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

我做我的改变 2024-10-10 22:44:02

你看到什么了? HttpCacheWrapper 对它传递的 HttpRuntime.Cache 做了什么?

我怀疑您所看到的是缓存策略,该策略对于缓存的速率而言保留事​​物的时间太长。正如 Raymond Chen 所说,“不正确的缓存策略与内存泄漏没有区别。”

我隔离此问题的方法是尝试使用您拥有的策略仅使用一个存储库进行测试。查看是否出现性能问题。

如果没有,则继续创建第二个存储库并密切监视内存使用情况。

What are you seeing? What does HttpCacheWrapper do with the HttpRuntime.Cache it gets passed?

I suspect that what you're seeing instead is a cache policy that holds onto things too long for the rate that things are being cached. As Raymond Chen has said, "incorrect cache policy is indistinguishable from a memory leak."

The way I would isolate this is to try to test with just one repo using the policy you have. See if your performance problems appear.

If not, then go ahead and create the 2nd repo and closely monitor memory usage.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文