如何衡量 PHP 脚本的效率

我想知道什么是最好的方式来基准我的 PHP 脚本。无论是一个 cron 作业，或网页或 Web 服务。

我知道我可以使用微时，但它真的给了我一个 PHP 脚本的实时性吗？

我想在 PHP 中测试和基准测试做同样事情的不同函数。例如，preg_match vs strpos或 domdocument vs preg_match或 preg _ place vs str _ place’

网页示例:

<?php
// login.php


$start_time = microtime(TRUE);


session_start();
// do all my logic etc...


$end_time = microtime(TRUE);


echo $end_time - $start_time;

这将输出: 0.0146126717(一直在变化——但这是我得到的最后一个)。这意味着执行 PHP 脚本需要0.015左右的时间。

还有更好的办法吗？

94917 次浏览
小开

把它放在 for循环中，每件事做100万次，得到一个更实际的数字。并且只能在您实际想要进行基准测试的代码之前启动计时器，然后在此之后记录结束时间(即不要在 session_start()之前启动计时器。

还要确保代码对于要进行基准测试的每个函数都是相同的，除了计时的函数。

脚本的执行方式(cronjob、来自命令行的 php、 Apache 等)不应该有什么不同，因为您只是计算不同函数速度之间的相对差异。所以这个比例应该保持不变。

如果您正在运行基准测试的计算机上运行许多其他事情，那么如果在基准测试运行时其他应用程序的 CPU 或内存使用正好出现峰值，则可能会影响基准测试结果。但是只要你在电脑上有很多闲置资源，那么我不认为这会是一个问题。

小开
最佳答案

如果您实际上想要对现实世界的代码进行基准测试，那么可以使用像 Xdebug和 XH 教授这样的工具。

Xdebug 非常适合于在 dev/stage 中工作，而且 XHProfessor 是一个非常好的生产工具，在那里运行它是安全的(只要您阅读了说明)。任何一个页面加载的结果都不会像查看您的代码执行情况那样重要，因为服务器正在处理成千上万的其他事情，而且资源变得稀缺。这引发了另一个问题: 您是否在 CPU 上遇到瓶颈？RAM？输入/输出？

您还需要看到脚本中运行的代码之外，脚本/页面是如何被服务的。你用的是什么网络服务器？作为一个例子，我可以让 nginx + PHP-FPM 严重超过执行 mod _ php + Apache，而后者因为使用好的 CDN 提供静态内容而受到打击。

下一件需要考虑的事情是你正在试图优化什么？

  • 页在用户浏览器中呈现的速度 第一优先？
  • 将发送到服务器的每个请求以同样快的速度抛出 可以用最小的 CPU 消耗的目标？

前者可以通过诸如 gzip 所有发送到浏览器的资源来实现，但是这样做可能(在某些情况下)使您更加无法实现后者。

希望上面的所有内容能够帮助我们认识到，精心隔离的“实验室”测试不会反映你在生产过程中遇到的变量和问题，而且你必须确定你的高级目标是什么，然后你可以做什么来达到这个目标，然后才能走下微观/过早优化 通往地狱的路的道路。

小开

你会想看看 Xdebug，更具体地说，Xdebug 的分析能力。

基本上，您启用分析器，每次您加载一个网页，它创建一个缓存文件，可以读取与 WinCacheGrind或 KCacheGrind。

Xdebug 的配置可能有点复杂，所以下面是我的 php.ini的相关部分，以供参考:

[XDebug]
zend_extension = h:\xampp\php\ext\php_xdebug-2.1.1-5.3-vc6.dll
xdebug.remote_enable=true
xdebug.profiler_enable_trigger=1
xdebug.profiler_output_dir=h:\xampp\cachegrind
xdebug.profiler_output_name=callgrind.%t_%R.out

下面是 WinCacheGrind中 .out文件的截图:

enter image description here

这将提供有关 PHP 脚本的效率的详细信息。你要瞄准那些花费时间最多的事情。例如，您可以用一半的时间优化一个函数，但是在页面加载期间优化一个被调用几十次甚至几百次的函数会更好。

如果您感到好奇，这只是我为自己使用而编写的 CMS 的一个旧版本。

小开

我会调查 Xhprof。无论是在 cli 上运行，还是通过另一个 sapi (比如 fpm、 fcgi 甚至 Apache 模块)运行，都没有关系。

关于 xhprof 最好的部分是，它甚至足够适合在生产环境中运行。一些在 xdebug 中不能很好地工作的东西(上次我检查的时候)。Xdebug 对性能有影响，而 xhprof (我不会说没有影响)管理得更好。

我们经常使用 xhprof 收集具有实际流量的示例，然后从中分析代码。

这不是一个真正的基准，它让你一个 时间和所有的，虽然它也这样做。它使分析生产流量变得非常容易，然后深入到所收集的调用图中的 php 函数级别。

一旦编译并加载了扩展，就可以在代码中开始分析:

xhprof_enable(XHPROF_FLAGS_CPU + XHPROF_FLAGS_MEMORY);

停止:

$xhprof_data = xhprof_disable();

然后将数据保存到一个文件或数据库中——不管是什么，只要不影响正常的运行时就可以了。我们异步地将其推送到 S3以集中数据(以便能够看到来自所有服务器的所有运行)。

Github 上的代码包含一个 xhprof _ html 文件夹，您可以将其转储到服务器上，通过最小的配置，您可以将收集到的数据可视化，并开始向下钻取。

哈！

小开

为了测试完整的脚本在服务器上运行的速度，您可以使用许多工具。首先确保您的脚本(例如 preg _ match vs strpos)必须输出相同的结果才能使测试合格。

你可使用:

小开

艾瑞克,

你问错问题了。如果你的脚本执行在15毫秒左右，那么它的时间基本上是无关紧要的。如果你在一个共享服务上运行，那么 PHP 镜像激活需要大约100mSec，如果在服务器上完全缓存，读取脚本文件需要大约30-50mSec，如果从后端 NAS 场加载，可能需要1秒或更长时间。加载页面家具时的网络延迟可能会增加很多秒。

这里的主要问题是用户对加载时间的感知: 他或她在点击链接和获得完全呈现的页面之间需要等待多长时间。看一看 谷歌网页速度，你可以用它作为 FF 或 chrome 扩展，以及 Pagespeed 文档，它深入讨论了如何获得良好的页面性能。遵循这些指导方针，试着让你的页面得分高于90/100。(谷歌主页得分99/100，我的博客也是)。这是获得良好的用户感知性能的最佳方法。

小开

试试 https://github.com/fotuzlab/appgati

它允许定义代码中的步骤，并在两个步骤之间报告时间、内存使用情况、服务器负载等。

比如:

    $appgati->Step('1');


// Do some code ...


$appgati->Step('2');


$report = $appgati->Report('1', '2');
print_r($report);

输出数组示例:

Array
(
[Clock time in seconds] => 1.9502429962158
[Time taken in User Mode in seconds] => 0.632039
[Time taken in System Mode in seconds] => 0.024001
[Total time taken in Kernel in seconds] => 0.65604
[Memory limit in MB] => 128
[Memory usage in MB] => 18.237907409668
[Peak memory usage in MB] => 19.579357147217
[Average server load in last minute] => 0.47
[Maximum resident shared size in KB] => 44900
[Integral shared memory size] => 0
[Integral unshared data size] => 0
[Integral unshared stack size] =>
[Number of page reclaims] => 12102
[Number of page faults] => 6
[Number of block input operations] => 192
[Number of block output operations] =>
[Number of messages sent] => 0
[Number of messages received] => 0
[Number of signals received] => 0
[Number of voluntary context switches] => 606
[Number of involuntary context switches] => 99
)

提交答案