当遇到新的页面被请求时会自动进行检索

当遇到新的页面被请求时会自动进行检索

随着Sitecore现在的操作，当新的非缓存页面被请求时，Sitecore连接到Azure SQL，并检索它们。如果我们遇到了足够多的未缓存的内容，我们将大限度地减少20个DTU限制，页面响应时间将会增加，用户可能会遇到超时。当然，如果常见的内容被缓存，则不会发生这种情况。因此，这为Sitecore、CDN和热身脚本的缓存优化提供了一个很好的理由。

或者，您也可以将每个DB基础上的大小增加到一个S2，一直到S3。

我有一些实际的数据可以在这里分享，这样您就可以看到S1和S3之间的实际差异。我在2016年为Sitecore研讨会创建了一个测试设置，我在Sitecore IaaS、Sitecore上使用了PaaS，还测试了一个混合选项，在IaaS上托管Sitecore，但使用了Azure SQL作为数据库层。

使项目Guttnberg和aspx终创建了一个1.2 GB的主DB和700MB的web DB。我注意到，如果使用默认的缓存设置，如果使用Sitecore 8.2升级1，CD将完成预缓存，并在3分钟后重启IIS。切换到WebDB的S1，Sitecore将会超时，而且永远不会转变成操作，因为S1实例已经被它的DTUs所使用。切换到S2，同样的问题也出现了，但是在将SQL超时更改为一个小时后，我就开始工作了。事实上，在45分钟后，Sitecore将会运作。切换到S3，IIS重启时间减少到15分钟。

现在，您可以禁用预缓存，并将此时间进一步缩短。但老实说，500k文本内容丰富的内容是很多文本。我也很关注资产/丰富的媒体。

我还使用jMeter进行了一些基准测试，将一个Azure SQL S3和一个运行SQL Std的DS3 v2进行比较，负载明智的我应用了250个并发连接。

配置吞吐量（每秒页面）平均页面延迟（ms）页面延迟99个百分点（ms）页面延迟大（ms）错误

SQL Azure。S3 Web-xDB正常-共享会话状态InProc 67.2 415418610021 0

SQL Server DS3 v2与P20 SSD-xDB正常-共享会话状态InProc 70.2 22716087676 0

正如您可以看到的，Azure SQL配置每秒处理的页面数量类似，但页面延迟要高得多。在稍微低一点的负载下，我们可以得到2000毫秒以下的99个百分点，我认为对于大多数。com站点来说，这是一个小的页面响应时间。为什么延迟如此之高？我当时研究了它，我可以看到，DTU的Web DB是周期性的，这导致了更高的延迟。

我开始思考这个问题，比如国外VPS主机cn.blu***怎么样？在很多情况下，仅仅是碰到S3可能是将问题小化的简单的方法。然而，我也注意到，在这段时间内，核心和master的DTUs非常低。只有分析具有真正的DTU利用率，这是合理的，因为xDB同时也在运行。

如果我们可以使用这些未使用的DTUs……也许我们可以，使用第二种类型的Azure SQL风格。

ElasticPools

与每个数据库都有自己的固定DTU不同，弹性池将所有数据库放在一个共享的DTUs池中。还有一些机制限制了数据库可以使用的池的数量，因此您可以保留一些DTUs，以表示核心和主操作成功。