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