146

我想知道对我的 PHP 脚本进行基准测试的最佳方法是什么。不管是 cron 作业、网页还是 Web 服务。

我知道我可以使用 microtime，但它真的给了我 PHP 脚本的实时时间吗？

我想在 PHP 中测试和基准测试做同样事情的不同函数。例如preg_matchvs strposor domdocumentvs preg_matchor preg_replace vs str_replace`

网页示例：

<?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 左右。

有没有更好的办法？

4

7 回答 7

132

如果您真的想对真实世界的代码进行基准测试，请使用Xdebug和XHProf等工具。

Xdebug 非常适合您在 dev/staging 中工作，而 XHProf 是一个很棒的生产工具，在那里运行它是安全的（只要您阅读说明）。任何单个页面加载的结果都不会像查看代码的执行情况那样相关，而服务器也正忙于做一百万个其他事情并且资源变得稀缺。这引发了另一个问题：您是否在 CPU 上遇到瓶颈？内存？输入输出？

您还需要不仅查看您在脚本中运行的代码，还需要查看您的脚本/页面的服务方式。您使用的是什么网络服务器？例如，我可以让 nginx + PHP-FPM 在执行 mod_php + Apache 方面表现出色，而后者又因使用良好的 CDN 提供静态内容而受到打击。

接下来要考虑的是您要优化什么？

  • 页面在用户浏览器中呈现的速度是第一要务吗？
  • 目标是尽可能快地以最小的 CPU 消耗将每个请求返回到服务器吗？

前者可以通过 gzip 压缩发送到浏览器的所有资源来得到帮助，但这样做可能（在某些情况下）使您远离实现后者。

希望以上所有内容都可以帮助表明，仔细隔离的“实验室”测试不会反映您在生产中将遇到的变量和问题，并且您必须确定您的高级目标是什么，然后您可以做些什么来实现目标，在沿着微/过早的优化路线走向地狱之前。

于 2011-12-04T02:16:48.933 回答
78

为了对完整脚本在服务器上的运行速度进行基准测试，您可以使用很多工具。首先确保您的脚本（例如 preg_match vs strpos）必须输出相同的结果才能使您的测试合格。

您可以使用：

于 2011-12-04T02:35:32.590 回答
31

您将希望查看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中文件的屏幕截图：

在此处输入图像描述

这应该提供有关您的 PHP 脚本的效率的详细信息。您想针对花费最多时间的事情。例如，您可以优化一个函数以花费一半的时间，但您的努力会更好地优化一个在页面加载期间调用数十次甚至数百次的函数。

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

于 2011-12-04T02:17:17.717 回答
16

试试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
)
于 2013-06-23T08:21:11.047 回答
7

我会调查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 文件夹，您可以将其转储到服务器上，并且只需最少的配置，您就可以可视化收集的数据并开始向下钻取。

！

于 2011-12-04T02:34:29.677 回答
3

把它放在一个for循环中，每件事做 1,000,000 次以获得更现实的数字。并且仅在您实际要进行基准测试的代码之前启动计时器，然后在之后记录结束时间（即不要在session_start().

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

脚本的执行方式（cronjob、命令行中的 php、Apache 等）应该不会产生影响，因为您只是在计算不同函数速度之间的相对差异。所以这个比例应该保持不变。

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

于 2011-11-28T03:57:47.877 回答
0

埃里克，

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

这里的主要问题是用户对加载时间的看法：他或她在点击链接和获得完全呈现的页面之间需要等待多长时间。查看可用作 Ff 或 chrome 扩展的Google Page Speed ，以及深入讨论如何获得良好页面性能的 Pagespeed 文档。遵循这些准则并尝试让您的页面得分高于 90/100。（谷歌主页得分 99/100 和我的博客一样）。这是获得良好用户感知性能的最佳方式。

于 2012-01-24T18:30:46.020 回答