我正在ASP MVC3中创建一个基于成员的Web应用程序，我正在尝试提前计划，起初我们的用户群不会很大，但与任何软件一样，突然出现音量峰值的可能性总是存在的。
考虑到这种情况，我知道数据库是大多数网络应用程序的瓶颈区域。我们正在使用MSSQL 2008RS，我们将拥有带有多个客户端数据库的专用服务器，每个客户端都有自己的数据库，因此，如果一个服务器开始瓶颈，我们可以垂直扩展或将一些数据库移动到新服务器并开始填充它。
要访问数据库，我们主要使用LINQ 2 SQL，并且当前正在重新分解我们的一些代码，以利用IQueryable机制来执行延迟的内容加载。但是每个页面都包含来自数据库各个部分的相当多的内容。
我们还有一些大型数据库用于程序中的小部件，这些小部件很少更改，但有数百万行。这些目标是以某种方式将它们同步到主要源并将它们分布在多台计算机上，然后对这些服务器进行负载平衡。
使用这种布局我是否应该担心缓存，或者MSSQL中的内置缓存机制是否足够？
如果是的话我应该从哪里开始？我简要介绍了一下app fabric，但它看起来只适用于Azure？
资源：
答案 0 :(得分：2)
延迟加载是一种性能杀手。最好用一个连接加载整个对象图，而不是延迟加载其他属性。对象列表尤其如此。如果你迭代，你将最终延迟加载列表中的每个项目。此外，每次调用db都会产生开销。少打电话=更好的表现。
在需要两台数据库服务器之前，SO是排名前1000的网站。我想你会好的。
如果您的收入模型显示“每个客户端都有自己的数据库”，那么扩展问题应该很容易解决。听起来您已经有计划随着客户群的增加而扩展更多服务器。问题是什么？
在Web层上缓存通常是您必须担心的第一个扩展修复程序。您可能不需要为每个页面请求执行新的db调用。
总的来说，这听起来像很多过早的优化。您的流量尚未达到您需要担心缩放的程度。在最后一秒做出这些决定。
答案 1 :(得分：1)
数据库缓存与大多数缓存不同 - 如果将使用过的数据加载到内存中并重新使用查询计划，它就可以了，但这并不是真正的缓存。
AppFabric绝对不仅仅是天蓝色;毕竟，我是你无法在本地安装它（并使用它）:)但实际上AppFabroc，redis和memcached之间几乎没有（后者当然缺乏持久性）。
但我认为你应该最初看看使用内置的asp.net缓存;通过HttpContext.Cache进行数据缓存，以及缓存整个响应（或者，在MVC 3中，部分）。显然，您应该广泛了解大量请求会大量使用哪些数据，并且可以安全地重复使用：缓存！
请确保将所有缓存的FAA视为不可变（如果您需要更新缓存，重新添加修改后的值;请勿修改现有对象） - 原因：如果您启动它将无法正常工作需要使用分布式缓存，因为它使用序列化，并且下一个请求将不会看到您所做的任何更改。