简体   繁体   English

ASP.NET中的自定义缓存

[英]Custom caching in ASP.NET

I want to cache custom data in an ASP.NET application. 我想在ASP.NET应用程序中缓存自定义数据。 I am putting lots of data into it, such as List<objects>, and other objects. 我将大量数据放入其中,例如List <objects>和其他对象。

Is there a best practice for this? 是否有最佳做法? Since if I use a static data, if the w3p.exe dies or gets recycled, the cache will need to be filled again. 由于如果我使用静态数据,如果w3p.exe死掉或被回收,则需要再次填充缓存。

The database is also getting updated by other applications, so a thread would be needed to make sure it is on the latest data. 该数据库也正在被其他应用程序更新,因此需要一个线程来确保该数据库位于最新数据上。

Update 1: 更新1:

Just found this, which problably helps me 刚发现这个,可能对我有帮助

http://www.codeproject.com/KB/web-cache/cachemanagementinaspnet.aspx?fid=229034&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2818135#xx2818135xx http://www.codeproject.com/KB/web-cache/cachemanagementinaspnet.aspx?fid=229034&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2818135#xx2818135xx

Update 2: 更新2:

I am using DotNetNuke as the application, ( :( ). I have enabled persistent caching and now the whole application feels slugish. 我正在使用DotNetNuke作为应用程序(:()。我启用了持久缓存,现在整个应用程序都感觉很迟钝。

Such as a Multiview takes about 3 seconds to swap view.... 例如,多视图切换大约需要3秒钟。

Update 3: 更新3:

Strategies for Caching on the Web? 网络缓存策略?

Linked to this, I am using the DotNetNuke caching method, which in turn uses the ASP.NET Cache object, it also has file based caching. 与此链接,我正在使用DotNetNuke缓存方法,该方法又使用ASP.NET Cache对象,它也具有基于文件的缓存。

I have a helper: 我有一个助手:

CachingProvider.Instance().Add( _
    (label & "|") + key, _
    newObject, _
    Nothing, _
    Cache.NoAbsoluteExpiration, _
    Cache.NoSlidingExpiration, _
    CacheItemPriority.NotRemovable, _
    Nothing)

Which runs that to add the objects to the cache, is this correct? 哪个运行将对象添加到缓存中,这是正确的吗? As I want to keep it cached as long as possible. 因为我想让它尽可能长地缓存。 I have a thread which runs every x Minutes, which will update the cache. 我有一个线程,每x分钟运行一次,它将更新缓存。 But I have noticied, the cache is getting emptied, I check for an object "CacheFilled" in the cache. 但是我已经通知,缓存将被清空,我在缓存中检查对象“ CacheFilled”。

As a test I've told the worker process not to recycle, etc., but still it seems to clear out the cache. 作为测试,我告诉工作进程不要回收,等等,但是似乎仍然清除了缓存。 I have also changed the DotNetNuke settings from "heavy" to "light" but think that is for module caching. 我也将DotNetNuke设置从“重载”更改为“轻载”,但认为这是用于模块缓存。

Also have a look at the MS Enterprise Caching Application block which allows your to write custom expiration policy, custom store etc. http://msdn.microsoft.com/en-us/library/cc309502.aspx 还可以查看MS Enterprise Caching Application块,该块允许您编写自定义过期策略,自定义存储等。http://msdn.microsoft.com/zh-cn/library/cc309502.aspx

You can also check "Velocity" which is available at http://code.msdn.microsoft.com/velocity 您还可以在http://code.msdn.microsoft.com/velocity上查看“ Velocity”

This will be useful if you wish to scale your application across servers... 如果您希望跨服务器扩展应用程序,这将非常有用。

You are looking for either out of process caching or a distributed caching system of some sort, based upon your requirements. 您正在根据自己的需要寻找进程外缓存或某种分布式缓存系统。 I recommend distributed caching, because it is very scalable and is dedicated to caching. 我建议使用分布式缓存,因为它具有很高的可扩展性,并且专门用于缓存。 Someone else had recommended Velocity, which we have been evaluating and thoroughly enjoying. 有人推荐了Velocity,我们一直在对其进行评估,并非常满意。 We have written several caching providers that we can interchange while we are evaluating different distributed caching systems without having to rebuild. 我们已经编写了几个缓存提供程序,我们可以在评估不同的分布式缓存系统而无需重建的情况下互换它们。 This will come in handy when we are load testing the various systems as part of the final evaluation. 当我们对各种系统进行负载测试作为最终评估的一部分时,这将派上用场。

In the past, our legacy application has been a random assortment of cached items. 过去,我们的旧版应用程序是随机分配的缓存项。 There have been DataTables, DataViews, Hashtables, Arrays, etc. and there was no logic to what was used at any given time. 已经有DataTables,DataViews,Hashtables,Arrays等,并且在任何给定时间都没有逻辑使用。 We have started to move to just caching our domain object (which are POCOs) collections. 我们已经开始转移到仅缓存域对象(即POCO)集合。 Using generic collections is nice, because we know that everything is stored the same way. 使用通用集合很不错,因为我们知道所有内容都以相同的方式存储。 It is very simple to run LINQ operations on them and if we need a specialized "view" to be stored, the system is efficient enough to where we can store a specific collection of objects. 在它们上运行LINQ操作非常简单,如果我们需要存储专门的“视图”,那么该系统的效率足以存储特定的对象集合。

We also have put an abstraction layer in place that pretty much brokers calls between either the DAL or the caching model. 我们还放置了一个抽象层,在DAL或缓存模型之间,几乎所有代理都调用了抽象层。 Calls through this layer will check for a cache miss or cache hit. 通过此层的呼叫将检查缓存未命中或缓存命中。 If there is a hit, it will return from the cache. 如果命中,它将从缓存中返回。 If there is a miss, and the call should be cached, it will attempt to cache the data after retrieving it. 如果未命中,并且应该缓存该调用,它将在检索数据后尝试缓存数据。 The immediate benefit of this system is that in the event of a hardware or software failure on the machines dedicated to caching, we are still able to retrieve data from the database without having a true outage. 该系统的直接好处是,如果专用于缓存的计算机发生硬件或软件故障,我们仍然能够从数据库中检索数据而不会造成真正的中断。 Of course, the site will perform slower in this case. 当然,在这种情况下,网站的运行速度会变慢。

Another thing to consider, in regards to distributed caching systems, is that since they are out of process, you can have multiple applications use the same cache. 关于分布式缓存系统,要考虑的另一件事是,由于它们不在进程内,因此您可以让多个应用程序使用同一缓存。 There are some interesting possibilities there, involving sharing database between applications, real-time manipulation of data, etc. 那里有一些有趣的可能性,包括在应用程序之间共享数据库,实时处理数据等。

There are lots of articles about the Cache object in ASP.NET and how to make it use SqlDependencies and other types of cache expirations. 关于ASP.NET中的Cache对象以及如何使它使用SqlDependencies和其他类型的缓存过期的文章很多。 No need to write your own. 无需自己编写。 And using the Cache is recommended over session or any of the other collections people used to cram lots of data into. 并且建议在会话或人们用来填充大量数据的任何其他集合中使用Cache。

Cache and Session can lead to sluggish behaviour, but sometimes they're the right solutions: the rule of right tool for right job applies. 缓存和会话可能会导致性能下降,但有时它们是正确的解决方案:适用正确工作的正确工具规则适用。

Personally I've often created collections in pseudo-static singletons for the kind of role you describe (typically to avoid I/O overheads like storing a compiled xslttransform), but it's very important to keep in mind that that kind of cache is fragile, and design for it to A). 就我个人而言,我经常以伪静态单例为您描述的角色创建集合(通常是为了避免诸如存储已编译的xslttransform之类的I / O开销),但请务必牢记此类缓存易碎,并为其设计A)。 filewatch or otherwise monitor what it's supposed to cache where appropriate and B). filewatch或以其他方式监视应该缓存的内容,以及B)。 recreate/populate itself with use - it should expect to get flushed frequently. 使用时重新创建/填充自身-它应该期望经常刷新。

Essentially I recommend it as a performance crutch, but don't rely on it for anything requiring real persistence. 本质上,我将其推荐为性能拐杖,但对于任何需要真正持久性的东西,请不要依赖它。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM