我们有一个ASP.NET 4.0应用程序，它从数据库中提取一个复杂的数据结构，需要12个多小时才能推入内存数据结构（后来存储在HttpRuntime.Cache中）。数据结构的大小正在迅速增加，如果应用程序重新启动，我们无法继续等待12个多小时才能将其存入内存。如果要更改web.config或Web应用程序中导致重新启动的任何代码，这是一个主要问题 - 这意味着在使用应用程序之前需要等待很长时间，并阻碍开发或更新部署。
数据结构必须在内存中以使网站可用的速度工作。在内存数据库中，例如memcache或Redis，与HttpRuntime.Cache相比速度较慢，并且在我们的情况下无法工作（在内存中db必须序列化put / get，加上它们不能互相引用，它们使用的是查找键 - 降低性能，加上大量密钥，性能迅速下降）。性能是必须的。
我们想要做的是在应用程序结束之前（重新启动时）快速将HttpRuntime.Cache转储到磁盘，并且能够在应用程序再次启动时立即将其加载回来（希望在几分钟内而不是12小时以上或天）。
内存中的结构大约为50GB。
有解决方法吗？
答案 0 :(得分：8)
在内存数据库中，例如memcache或Redis，与HttpRuntime.Cache相比速度较慢
是的，但与12小时以上的旋转相比，它们非常快。就个人而言，我认为你在这里采取了错误的方法来强制加载50 GB的结构。只是一个建议，但我们使用HttpRuntime.Cache作为多层缓存策略的一部分：
关键是，在加载时我们不会要求内存中的任何内容 - 它会在需要时填充，从那时起就很快。我们还使用pub / sub（再次由redis提供）来确保缓存失效是及时的。最终结果：在寒冷时它足够快 ，在温暖时非常快。
基本上，我会查看避免需要50GB数据的任何内容，然后才能执行任何。
如果此数据不是缓存，而是数据，我会查看正确对象模型的序列化。我建议protobuf-net（我作为作者有偏见）作为一个强有力的候选人 - 非常快和非常小的输出。