我们需要我们的 Sitecore Web 应用程序每秒处理 60-80 个 Web 请求。我们使用的是 Sitecore 7.0。我们尝试了 1 个 Webserver + 1 个数据库服务器部署，但它每秒只处理 20-25 个请求。Web 服务器将内存中的所有其他请求排队。当我们增加负载时，内存会被填满。（我们做了所有推荐的 Sitecore 性能增强）。我们需要 4 倍的性能才能达到目标 :)。
是否可以通过升级现有服务器来实现这个目标，或者我们必须在生产环境中添加更多的 Web 服务器。
注意：我们也在使用 Lucene 索引。
在不改变部署的整体架构的情况下，您可以考虑以下一些事项
CDN 卸载媒体和静态资产请求
这使您的内容交付服务器可用于处理重要的内容查询和显示逻辑。
配置和使用 Sitecore 的内置缓存
这是来自指南：
Sitecore 缓存的调查和配置分为多个任务。这样，每项任务都更加集中和简化。重点是 Sitecore 数据库缓存（预取、数据和项目缓存）的配置和调整。
对于输出渲染缓存属性的配置，客户应了解 Sitecore 缓存配置参考和 Sitecore 演示组件参考，以了解如何正确启用这些缓存以及使这些缓存过期的属性。
查找慢查询或控件
听起来您的应用程序遵循 Sitecore 最佳实践，但我将此注释留给任何可能找到此答案的人。使用 Sitecore 的内置调试模式来识别运行最慢的控件和子布局。此外，如果您设置了 Analytics，则会有一个“慢页面”报告，它可能会为您提供一些关于您的应用程序在哪里变慢的信息。
话虽如此，如果您准备提供额外的服务器并设置负载平衡环境，请继续阅读。
分离内容交付和内容管理
对我来说，负载平衡内容交付服务器之前的第一个逻辑步骤是将内容管理与等式分开。这非常简单，Scaling Guide将引导您设置 HistoryEngine 以使这些 Lucene 索引保持最新。
使用 2 个或更多内容交付服务器设置负载均衡器
完成第一步后，这就像克隆内容交付服务器并将其添加到负载均衡器“池”一样简单。这里有几件事需要考虑，例如：您的 Web 应用程序是否允许用户登录？因此，您需要担心粘性会话或机器密钥。您的 Web 应用程序是否使用文件媒体而不是 blob 媒体？我不必处理这个问题，但我知道这是另一个考虑因素。
扩展您的 SQL 解决方案
我已经看到应用程序具有多达四个负载平衡的内容交付服务器，并且 SQL Server 没有问题 - 我认为这对于每种情况都是独一无二的，具体取决于许多因素：马力和 SQL Server 的调整、应用程序的内容模型、查询的复杂性、内容交付服务器上的缓存配置等。同样，扩展指南涵盖了 SQL 镜像和故障转移，因此这将是您实现这一目标的第一站。
最后，我想说联系 Sitecore。这些人可能已经看到了更多正确的地方和安装的错误之处，并且可以让您走上正确的道路。祝你好运！
这个答案是从 Sitecore 开发人员的角度写的：
底线：您需要准确找出性能瓶颈在哪里。这将需要一些挖掘，但将非常值得。您绝对应该能够毫无问题地处理 60-80 个请求/秒……但当然，这对您的站点和请求的性质做出了很多假设。
对于我的网站，我发现 Sitecore 的缓存实现低于标准...我在我的应用程序中创建了一些非常简单且具有侵略性的特定于应用程序的缓存，这让世界变得与众不同。例如，我们有 900 多个“合作伙伴”项目，我们的网站的广告都在其中...并且只需将所有这些对象放在 Application 对象中的数组中即可显着加快页面请求。在由 Item.Name 或 ID 索引的 Hashtable 中查找对象将比 Sitecore.Context.Database.GetItem("/itempath") 或 SelectItems() 调用快得多（至少，这是我的经验）。如果您的架构和数据集允许这种策略，我们在这方面有很好的经验。
另一件需要注意的是 XSLT 渲染。就个人而言，我完全避免使用它们，而支持 ASP.NET UserControls。XSLT 呈现速度很慢。比呈现相同 HTML 的原生 UserControl 慢 10 倍。因此，如果您有其中的一些……用一些自定义代码替换，您会看到一个不同的世界。