IIS 8.5失败的请求跟踪报告所用时间为0

Question

我安装了一些失败的请求跟踪(在Windows Server 2012上的IIS 8.5中)，以尝试和分析为什么某些页面加载比其他页面花费更长的时间。我们有一种情况，有时一个页面会在几秒钟内加载，而另一些时候则需要20秒才能处理。所以我希望我可以使用FRT来帮助我分析那些需要很长时间的时间。

这个question here非常相似，但它确实显示了一点时间，而我的不是，而且我的问题与传输时间无关(至少不是在IIS和我之间)。

这不仅仅是静态HTML。这些页面是由PHP动态生成的，PHP反过来调用数据库来检索信息。我希望辨别IIS和PHP之间的时间差异，但我的日志文件都显示FRT的每个元素都为0时间(或0持续时间)。

因为我不知道哪个部分会准确地报告我想要什么，所以我有点像猎枪一样，但这是我的配置：

Content = All 
Conditions:  Time = 2 (which is >2 if I read the help file correctly) 
Trace Providers:  ISAPI Extensions (verbose), WWW
Server (verbose)
  *  For WWW Server I have marked each of the 'Areas'

PHP的编码方式是，它还会报告所需的时间。这告诉我在某些情况下需要6-8秒。(这是一个专门为此目的而设计的测试文件，因此它会执行50个查询，并报告整个时间。)但是，有时在该运行中有一个查询需要15-20秒来处理。虽然FRT日志确实记录了一个跟踪，但它会说所用的时间只有2.532秒(举个例子)，即使PHP (和挂钟)显示它是6-8秒。但是，再一次，查看FRT日志的详细信息，它只显示所用时间的0，而不管实际花费了多长时间。

我真正想看到的是PHP调用花费了多长时间；IIS必须等待调用完成，然后才能返回结果，所以它看起来像是被记录了下来……

谢谢，贾斯汀

Answer 1

当您将FRT的时间限制为2时，跟踪将在已不幸达到2秒的阶段停止。

有几种方法可以绕过它。如果它位于可以限制流量的机器上，比如开发或测试平台，那么您可以将其设置为跟踪状态码为'200‘的结果。它将记录所有成功的(但长时间运行的)请求。

如果这是不可能的，那么将跟踪设置得更接近问题时间刻度将会有所帮助。因此，在您的示例中，将其设置为6秒，您将看到该过程的所有阶段，直到运行完的阶段