我的Azure帐户上托管的Umbraco网站的性能非常慢。该帐户运行两个站点，两个站点都设置为extrasmall大小，并运行两个实例进行故障转移。
为清晰度而编辑 -
每个实例中有两个可用的站点。在这两个站点中，一个工作正常，另一个工作很慢（尽管从同一个实例提供服务，同样的IIS等）。
-
我从检查Azure实例开始，它们似乎没问题，并没有特别挣扎（通常的工具：任务管理器，资源监视器，perfmon等）。这两个站点都是从SQL Azure运行的，似乎几乎没有滞后。
接下来，我使用?umbdebugshowtrace=true查询字符串运行我的缓慢网站，并且大部分延迟发生在页面生命周期的此时：
Category Message FromFirst(ms) FromLast(ms)
umbracoMacro Before performing transformation 0.858817787142857 0.000024
Resolve Urls 0 11.9020404352381 11.043223
umbracoMacro After performing transformation 11.9022704233333 0.000230
运行XSLT转换大约需要11秒。
所以我做了一些调查性的黑客行为，基本上剥离了页面上的每个XSLT控件，一次一个，没有一个（单独）似乎导致挂起。
是否有人建议我如何进一步深入研究这一点，或者可以获得有关延迟确切位置的更多信息？
我有足够的数据将其缩小到XSLT转换问题，这很棒，但更多信息会很棒：）
非常感谢任何建议！
卡尔。
答案 0 :(得分：0)
如果这是一个实例而不是另一个实例的问题，我认为您可能遇到Azure的一个问题：您不是服务器上唯一的租户。
像XSLT转换这样的东西确实非常耗费资源;根据转换，可能需要相当数量的CPU来处理。
您可以通过重新映像（不重新启动）实例来确认这一点。据我所知，这将在Azure基础架构中创建一个新的虚拟机，希望它可以位于不同的物理机器上。
如果这样可以解决问题，那么调查更大的实例大小可能是值得的。这会获得更多内存，而且我也理解它也会获得更高的CPU使用优先级。
另外：检查有问题的机器在虚拟内存上运行不低。进行大量字符串分配的XSLT转换会给内存带来额外压力，因此您可能会看到额外的垃圾收集。
答案 1 :(得分：0)
我认为禁用一部分控件（不是一个一个）是一种实用的方法。
事实上，人们可以像二元搜索程序那样做：
基础：如果您只有一个控件，则这是错误的控件
禁用一半控件并尝试。如果效率低下，那么罪魁祸首就是残疾人的一半 - 如果没有，那么就是剩下的一半。
继续递归，将2.上面应用于包含错误控件的控件集。
答案 2 :(得分：0)
转换在启动后11秒结束的事实并不一定意味着XSLT执行需要11秒。它可能花了大部分时间等待它开始之前所需的资源。例如，一个常见的原因是转换引擎调用XML解析器，XML解析器请求从远程网站获取DTD。