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