我正在开发一个社交网站。
从项目的第一天开始，我就一直在考虑可扩展性，我已经尽我所能对网站和查询进行了微调。
然而; 某些页面的数据量很大，我不太确定它们是否加载得尽可能快，所以我正在考虑实现一个分布式缓存解决方案。
但不太确定我应该缓存什么而不是缓存。或者，如果当前页面加载时间为 1 秒是好是坏。
最繁重的查询是获取会员信息 此查询获取所有会员的信息以及与他们相关的任何信息，例如在本网站的情况下他们的目标、博客类型条目、鼓励、照片、状态更新（如 twitter）、博客信息（用于交叉发布他们的条目) 等等等等。
无论如何，我应该缓存这些信息吗？你认为 1 秒的页面加载时间相当快吗？有些页面在 4-6 十分之一秒之间不到一秒。
典型的答案是：
在您的情况下，您可以将所有内容缓存在平面文件中（例如每个用户一个文件），并在相应内容更新时销毁用户缓存文件。如果缓存文件不存在，则在显示相关内容之前创建它。
现在关于加载时间（根据用户位置可能会有很大不同），这里有一些来自游戏网站 PHP 论坛的信息数字：
这被社区认为是一种很好的体验。但这是非常主观的。
如果可能的话，我会在应用程序的每一层实现缓存。
您可以在最高级别缓存页面，在代码级别缓存对象，并确保您的数据库在最低级别正确缓存查询和关键数据。
就您需要缓存的内容而言，任何将被重复访问的对象都应该被缓存，尤其是那些不太可能经常更改的对象。然后，您可以仅在编辑该对象时重置该对象的缓存。（注意缓存频繁更新的对象，因为在几乎每次加载时更换缓存的恒定循环会降低性能而不是提高性能）
为了衡量性能，我不会查看加载单个页面需要多长时间，而是使用谷歌搜索一些性能测量工具，因为您确实需要测试每个页面在压力下的执行速度。例如，如果您的用户信息页面很少被访问，它可能不是最大的缓存目标。您应该专注于使用最频繁的页面。
页面加载问题已经被问到：
对于动态的、个性化的 Web 应用程序，什么被认为是好的响应时间？
在缓存方面，您必须衡量每次加载数据与从缓存加载所花费的时间。缓存越大，它的效率就越低。因此，您不想将太多数据加载到缓存中。我们在这里使用的是滚动缓存，一旦达到缓存大小限制，最近最少使用的数据就会被丢弃。然后根据实际性能结果调整限制。
对于用户配置文件的特定数据，尽可能多地存储在 FormsAuth 票证/cookie 中。缓存（HttpContext.Current.Cache）用户特定的项目将需要每个用户在服务器上的 X 资源，与会话相同（但不那么令人头疼）。如果您可以将尽可能多的负载卸载到用户 Ticket 或 cookie（类似于 4K）中，那么您将真正帮助您的服务器在扩展时提高性能。
您应该只检索页面需要的信息位。例如，如果您正在加载博客数据，请不要加载照片。是的，它的工作量更大，但是如果您想扩展，则必须分析每个页面的需求。
确保您了解数据库查询缓存（执行计划重用）、对象缓存（Httpcontext.Cache）和页面缓存（Response.Headers[Expires]）之间的区别。
网页设计大师文森特·弗兰德斯 ( Vincent Flanders ) 建议，任何超过 4 秒的内容对于网页加载来说都太长了。我认为这是一个很好的经验法则。
就缓存或其他性能优化而言，我建议您进行一些性能测试。市场上有许多性能测试套件。测试将显示问题区域在哪里。将缓存逻辑添加到已经表现良好的东西是没有意义的。另一方面，性能问题可能会出现在您可能没有预料到的地方，涉及您可能没有考虑过缓存的数据。
我在性能测试中还发现，它可以在代码中找到发生死锁的地方，或者简单的数据库优化会有所帮助的地方。也许向表添加索引会加快页面速度，而不是添加一堆缓存逻辑。
我会保持简单，只在你需要的地方重构性能。
此外，尽早测试并经常测试。我知道很多人说要最后考虑性能，但是如果您至少在开发生命周期的早期就开始考虑它，那么您真的可以将自己编码到一个角落。
一些研究表明，交互式应用程序必须在 250 毫秒内提供反馈，以免用户认为它被卡住或操作失败。不过，网络上的接受程度要高一些，并且通常由网络浏览器提供正在加载新页面的反馈。使用 AJAX，您必须注意提供某种反馈，因为浏览器不会显示正在发生的事情。