最佳实践-在application_start中加载大量内容
本文关键字：加载 start application 最佳 | 更新日期: 2023-09-27 18:27:44
我有一个网店，里面有很多产品和其他内容。目前，我在Application_Start将所有内容加载到全局列表中，这大约需要15-25秒。
这使得网站非常快速，因为我可以在O（1）时间内获得任何产品/内容。
然而，这是最佳实践吗
目前，我有一个网络旅馆，它不是VPS/专用服务器，所以它会不时地回收应用程序，这会给随机访问者提供长达15-25秒的加载时间（只会随着内容的增加而变得更大）。这当然是完全不可接受的，但我想这会通过VPS来解决。
做这件事的正常方式是什么？我想像亚马逊这样的网店可能不会把他们所有的产品都加载到一个巨大的列表中：-D
任何想法和想法都将不胜感激。
您似乎已经回答了您的案例的问题"这当然是完全不可接受的"。
如果您的目标是O（1），则对单个产品的数据库的正常请求很可能是O（2），除非您需要在产品之间进行复杂的联接。考虑删除所有预缓存逻辑，看看性能是否有问题。您可以通过延迟缓存来限制启动影响。
大型站点通常使用分布式缓存，如MemcaheD。
更具可扩展性的设置是设置一个web服务来提供内容，网站在需要时会调用该服务。web服务需要缓存经常需要的内容，以实现快速响应。
首先，15-20秒加载数据的时间太长，所以我怀疑这种情况是
- 此时间用于编译而非数据加载
- 数据太多，内存已满
- 你用来读取数据的方法很慢
- 数据存储太慢，或者结构位于文本文件上，读取速度慢
我的观点是，你只缓存少量的数据，你需要在短时间内使用太多次。出于某些原因，你描述它的方式不是一种好的做法。
- 如果有多个池，那么在所有池中读取相同的数据，并且毫无理由地占用内存
- 您缓存的数据不能更改-仅供读取
- 即使缓存了一些数据，也需要渲染页面，而实际上需要在最终渲染时进行缓存，而不是在数据上
缓存内容和方式。
- 我们缓存最终呈现页面
- 我们还为客户端设置页面和其他元素的缓存
- 他更清楚，我们从数据库中读取和写入数据，然后让数据库缓存
- 如果我们缓存数据，那么它们必须是长循环所需的少量数据，并且我们多次避免数据库调用
此外，我们根据他们的要求进行缓存，如果长时间不使用，或者内存需要空间，这部分缓存就会消失。如果数据的某一部分来自多个表的复杂组合，那么我们会制作一个临时的平面大表，将所有数据放在一起，一行中的每一个数据都放在一起。这个表是临时的，如果我们需要太多，我们会制作第二个临时数据库文件来保存这部分数据。
数据库读取速度有多快？速度太快了，你不需要担心，你需要检查其他延迟点，比如我说的页面的完整呈现，或者页面的某些部分。
您需要担心的是一个好的数据库设计，一个快速检索数据的好方法，以及一个显示数据的好的优化代码。
职责分离将帮助您扩展到未来。
根据您当前的设置，您的网络服务器资源有限，而且，正如您所说，随着您继续添加更多产品，您的启动时间将失控。
如果与SQL Server分担每个页面请求的负担，则打开应用程序以允许其根据需要进行扩展。随着时间的推移，您可能会决定添加更多的web服务器、集群SQL Server，或者完全切换到新的数据库后端。然而，如果所有的负担都在应用程序池上，那么您就大大限制了自己。