你能弄清楚这个PHP计时问题吗？

Question

任何人都可以告诉我为什么当我运行具有以下内容的脚本然后在5秒后停止它，我需要将经过时间除以2以获得正确的脚本执行时间？

ignore_user_abort(true); set_time_limit(0); 

$begin_time = microtime(true);

$elapsed_time = 0;

while(!connection_aborted()) {
    echo ' ';
    flush();
    usleep(1000000);
}

$elapsed_time = microtime(true) - $begin_time;

$timer_seconds = $elapsed_time; //10 seconds

$timer_seconds = $elapsed_time / 2; //5 seconds


/*I am writing to a DB - but you can use this to test */
$fp = fopen('times.txt', 'w');
fwrite($fp, 'Time Elapsed: '.$timer_seconds);
fclose($fp);

随意尝试代码，因为它让$elapsed_time需要除以2的原因让我感到困惑。 也许我误会了什么？

谢谢大家的帮助

更新

我已更新代码，以便任何人都可以尝试这个，它将写入文本文件以查看输出。

Answer 1

实验：

原始代码发生重大变化：

1）使用implicit_flush并在执行任何操作之前刷新所有缓冲区。
2）代码不输出空格，而是输出迭代次数和1023字节的其他数据，告诉浏览器我们要显示的输出量很大。 一个正常的已知技巧。
3）除了节省输出文本文件中的时间外，它还节省了代码运行的总迭代次数。

使用的代码：

<?php
// Tricks to allow instant output
@ini_set('implicit_flush', 1);
for ($i = 0; $i < ob_get_level(); $i++)
    ob_end_flush();
ob_implicit_flush(1);

//Your Code starts here
ignore_user_abort(true);
set_time_limit(0); 

$begin_time = microtime(true);
$elapsed_time = 0;

while(!connection_aborted())
{
    //this I changed, so that a looooong string is outputted
    echo $i++.str_repeat(' ',1020).'<br/>';
    flush();
    usleep(1000000);
}

$elapsed_time = microtime(true) - $begin_time;
$timer_seconds = $elapsed_time; //10 seconds

//Writes to file the number of ITERATIONS too along with time
$fp = fopen('4765107.txt', 'w');
fwrite($fp, 'Time Elapsed: '.$timer_seconds);
fwrite($fp, "\nIterations: ".$i);
fclose($fp);
?>

现场演示：

• 现在，这是运行的代码： http ： //work.sktnetwork.com/so/4765107.php

• 这是它生成的.TXT文件： http ： //work.sktnetwork.com/so/4765107.txt

---

我得到了什么：

1）当代码运行10次迭代并且单击浏览器上的STOP按钮时，输出文件显示13次迭代，采用~13.01秒。

2）当代码运行20次迭代并且单击浏览器上的STOP按钮时，输出文件显示23次迭代，采用~23.01秒。

---

推论和结论：

1）当单击STOP按钮但单击2-4秒后，脚本实际上不会停止。 因此，浏览器中会出现更多迭代。

2）迭代次数是SAME，即执行所需的秒数，如输出文件所示。

因此，没有错误，显然没有错误，只是单击STOP按钮和实际停止的脚本之间的延迟时间。

---

笔记：

1）服务器：Linux VPS。
2）测试的客户端：Firefox和Chrome。
3） 当脚本在单击STOP后2-4秒结束时，输出文件需要大约3-4秒才能更新当前测试。

Answer 2

摘要:(这篇文章在我测试各种途径时变成了史诗）

PHP通常需要两次循环迭代来检测断开连接或提供输出。 此延迟可能来自Web服务器软件，主机，客户端计算机和客户端浏览器，但它应根据每次迭代的睡眠而变化。 更有可能的是，延迟来自PHP的内部执行或输出过程（可能来自一个小的内部缓冲区或中断处理过程）。

史诗贴：

从[Refresh]或URL-submit计算执行时间并不是一个准确的起点 - 可能需要先执行任意数量的步骤，这可能会增加延迟：

1. 需要DNS查找（使用TCP开销）
2. 与服务器建立TCP连接
3. Web Server创建一个线程或子项
4. Web Server决定如何处理请求
5. PHP可能需要启动
6. PHP可能需要将您的源转换为操作码

因此，不是测量[刷新] - > [停止]时间并将其与PHP记录的数字进行比较，而是测量显示输出到记录输出 - 这将延迟测量减少到大部分只在PHP内（尽管服务器/浏览器会起作用）。 修改后的脚本无法运行（它在固定次数的迭代后终止），清除默认的php.ini缓冲，并在屏幕和计时文件中报告迭代计数。 我用各种$sleep周期运行脚本来查看效果。 最后的剧本：

<?php
date_default_timezone_set('America/Los_Angeles'); //Used by ob apparently
ignore_user_abort(true); //Don't terminate script because user leaves
set_time_limit(0); //Allow runaway script !danger !danger
while (@ob_end_flush()) {}; //By default set on/4K in php.ini

$start=microtime(true);

$n=1000;
$i=0;
$sleep=100000;// 0.1s
while(!connection_aborted() && $i<$n) {
    echo "\n[".++$i."]";flush();
    usleep($sleep);
}

$end=microtime(true);

file_put_contents("timing.txt",
    "#\$sleep=".($sleep/1000000).
      "s\n/ s=$start / e=$end ($i) / d=".($end-$start)."\n",
    FILE_APPEND);
?>

结果:(连续多次运行，在Firefox中运行）

# On-screen $i / start utime / end utime (current $i) / delta utime

#$sleep=1s
2 / s=1296251342.5729 / e=1296251346.5721 (4) / d=3.999242067337
3 / s=1296251352.9094 / e=1296251357.91 (5) / d=5.000559091568
#$sleep=0.1s
11 / s=1296251157.982 / e=1296251159.2896 (13) / d=1.3075668811798
8 / s=1296251167.5659 / e=1296251168.5709 (10) / d=1.0050280094147
16 / s=1296251190.0493 / e=1296251191.8599 (18) / d=1.810576915741
4 / s=1296251202.7471 / e=1296251203.3505 (6) / d=0.60339689254761
16 / s=1296251724.5782 / e=1296251726.3882 (18) / d=1.8099851608276
#$sleep=0.01s
42 / s=1296251233.0498 / e=1296251233.5217 (44) / d=0.47195816040039
62 / s=1296251260.4463 / e=1296251261.1336 (64) / d=0.68735003471375
150 / s=1296251279.2656 / e=1296251280.901 (152) / d=1.6353850364685
379 / s=1296252444.7587 / e=1296252449.0108 (394) / d=4.2521529197693
#$sleep=0.001s
337 / s=1296251293.4823 / e=1296251294.1515 (341) / d=0.66925406455994
207 / s=1296251313.7312 / e=1296251314.1445 (211) / d=0.41328597068787
792 / s=1296251324.5233 / e=1296251326.0915 (795) / d=1.5682451725006

（Opera不显示数字，但显示大致匹配的最终数字）
（Chrome在测试期间/之后不显示任何内容）
（Safari在测试期间/之后不显示任何内容）
（IE在测试期间/之后不显示任何内容）

每行上的第一个数字表示按下[停止]后手动记录的屏幕上显示的数字。

几点：

• 您的停止点被量化为最接近的$sleep时段（上述脚本中的1 / 10s）因为脚本仅在每次迭代开始时检查，因为usleep方法不是完美的延迟，所以存在一些变化。
• 您正在使用的浏览器和服务器有所不同。 刷新手册页注释“可能无法覆盖Web服务器的缓冲方案，并且不会影响浏览器中的任何客户端缓冲。” 然后详细介绍服务器和客户端问题。 [ 服务器 ：WinXPsp3 / Apache 2.2.17 / PHP 5.3.3 客户端 ：WinXPsp3 / FireFox 3.6.13]

分析：

除了0.001s延迟之外，我们在[stop]和PHP捕获它（或Firefox或Apache报告）之间看到了2次迭代延迟。 延迟为0.001秒时，它会变化一点，平均值为~4次迭代或0.004秒 - 这可能接近检测速度阈值。

当延迟时间为0.1秒或更长时，我们看到执行时间与$sleep * {记录的迭代}紧密匹配。

当延迟时间低于0.1秒时，我们发现执行延迟大于休眠时间。 这可能来自检查客户端连接，增加$i ，输出文本以及每次迭代刷新缓冲区的成本。 执行时间和$i*$sleep之间的差异是非常线性的，表明完成这些任务需要大约0.001秒/迭代（0.01s睡眠时为0.0008，而0.001s睡眠时间为0.0010 - 可能是由于增加MALLOC /输出）。

Answer 3

当您点击浏览器中的“停止”按钮时，您依赖connection_aborted()是true ，但没有证据表明您已经验证了这种情况。 事实上，事实并非如此。

您忘记了网络中“连接中止”检查的方式。 应用程序（在这种情况下为php）在尝试写入管道之前不知道发生了什么。

对connection_abort()文档的第一条评论说：“为了检测脚本内部的断开连接，我们需要刷新缓冲区（只有当服务器尝试发送缓冲区内容时才会看到连接是破碎）。”

所以我不相信你能以这种方式可靠地使用connection_abort() 。

请放心， microtime()工作正常。

Answer 4

connection_aborted()只能在发送缓冲区时检测断开连接。 但flush()不一定发送缓冲区。 因此循环不断迭代，直到缓冲区被填满并且确实被刷新。

有关更多详细信息，请参阅指定功能的手册页。

Answer 5

使用您的脚本开箱即用，在Ubuntu上无法正常运行，使用Chrome访问该页面。 循环只是继续，不得不重启Apache。 另一方面，在顶部添加ob_end_flush（）可以解决该问题，而且计时器实际上是正确的。

ob_end_flush();
ignore_user_abort(true); 
set_time_limit(0);

$begin_time = microtime(true);

$elapsed_time = 0;

while(!connection_aborted()) {
    echo ' ';
    flush();
    usleep(1000000);
    error_log("looping");
}

$elapsed_time = microtime(true) - $begin_time;

$timer_seconds = $elapsed_time; 
error_log(var_export($timer_seconds, true));


$timer_seconds = $elapsed_time / 2; 
error_log(var_export($timer_seconds, true));

如果你运行它并查看错误日志，你会发现$ elpased_time在第一次运行时是正确的，不需要除以。 根据你的代码行为的原因，我不知道，因为它甚至不能在我的机器上工作。

Answer 6

这不是“问题”，而是“按设计”

它是http工作方式的一个功能。

当向客户端（浏览器）发送网页时，服务器“必须”发送内容长度标题。 现在，除非从脚本中获取所有内容，否则无法知道内容的长度。

因此服务器将缓冲脚本输出，直到脚本完成。

这是变幻莫测的进入的地方。根据服务器甚至同一服务器的不同版本，它可能会或可能不会检查客户端是否定期断开连接，如果是，那些检查可能是在不同的时间间隔。 甚至可能会根据服务器的繁忙程度而改变。

PHP无法控制与客户端的连接，它只能询问服务器连接是否仍然存在。 服务器可能会或可能不会说实话。 因此脚本继续运行（在服务器可能不知道的时候）。

那么为什么Mikushi的工作在脚本的START处添加了ob_end_flush（）之后呢？

好吧那就是因为它打开了另一个叫做chunk transfer的http功能。 这允许数据以块的形式发送，每个块都有一个特殊版本的内容长度头（实际上并没有这样说，它只发送下一个块长度）

尝试使用Wireshark的Mikushi脚本，您将看到编码，此处显示了一个示例

HTTP/1.1 200 OK
Date: Tue, 01 Feb 2011 11:52:35 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.1.6
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=UTF-8


7 <== this is the content-length 
<pre>0

2 <== this is the content-length 
1

2 ditto ...
2

2
3

2
4

2
5

所以这意味着它是不可能的（是的Tomalak，你让我:)）知道什么时候服务器将终止连接，因此为connection_aborted（）返回true，直到你测试所涉及的实际服务器。 因为每个人都不同。 即使是网络浏览器也可能会做一些延迟实际关闭的事情，这可能会使问题更加混乱。

DC