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