0

我开始使用 Xdebug 和 WinCacheGrind 来更多地了解我编写的代码。

我目前正在测试一个使用 MySQL 存储为持久会话的购物车对象。

以下是对象在典型的“添加到购物车”操作中执行的步骤：

  1. 构造一个填充有默认值的购物车会话
  2. 使用 $_COOKIE['session_id'] AND $_SERVER['REMOTE_ADDR'] 在 MYSQL 中检查现有的购物车会话。如果是这样，mysql 行会填充购物车会话 （12 毫秒）
  3. 在购物车中设置国家代码和州代码以进行进一步的运费计算。
  4. 添加项目
  5. 添加项目选项
  6. 根据国家代码和州代码从 MYSQL 获取运输选项（常规、快递、次日）（9.1 毫秒）
  7. 根据购物车中的商品重量计算每个选项的运费
  8. 设置折扣（0.1ms）
  9. 设置用户首选的运输选项，例如。常规的;
  10. 在 MYSQL (93ms)中保存购物车会话，使用 php 函数序列化购物车内容。
  11. 在 VIEW 中显示购物车值。

对 db 的唯一调用是在第 2、6、11 步。

当然会有额外的数据库调用来获取项目详细信息、项目选项和折扣代码。但是对于示例，我将其保持在最低限度。

对于这个 PHP 请求，XDebug 给出的结果是 Cumulative Time : 130ms。

不好吗？

我真正的问题是，请求应该以“毫秒”为单位有多快？我听说 YouTube 的目标是 200 毫秒 Total 但是，我不是谷歌，也没有从未来工程师那里回来的这支超超级天才激光智能 2055 团队......

谢谢您的帮助。

C。

4

1 回答 1

0

不幸的是，XDebug 中的分析本身给 PHP 程序增加了显着的性能开销。

因此，您不应依赖 XDebug 为您的代码提供以毫秒为单位的绝对速度数字。（而且你在测试平台上的表现不太可能成为现实世界中不同硬件和不同用户数量的性能指标）

相反，您应该专注于使用分析器输出来向您显示程序的哪些部分花费的时间最多。这些是您的瓶颈——无论程序实际运行的速度有多快，某些部分将占用超过其公平份额的处理器时间，这些是您应该重点改进的方面。这就是 XDebug 的分析器旨在帮助您解决的问题。

至于分析 XDebug 的输出，我强烈建议放弃 WinCacheGrind 并下载KCacheGrind。它是一个非常优秀的工具（主要是因为 WinCacheGrind 很久以前就停止了开发）。它具有一些出色的可视化工具，可以一目了然地了解您的代码的某些部分对整个系统的影响程度。

如果你真的需要知道你的绝对性能数据，你可以考虑从 XDebug 切换到 XHProf。XHProf 是 Facebook 为 PHP 编写的轻量级分析工具。它不像 XDebug 那样功能齐全（也没有成熟；直到最近才开始受到关注），但它更轻巧，并且在使用时对性能没有太大影响。我仍然会推荐 XDebug，因为它的功能要强大得多，但是这两种工具肯定都有它们的位置。

你可以在这里找到更多关于 XHProf 的信息：http: //blog.cnizz.com/2012/05/05/enhanced-php-performance-profiling-with-xhprof/

于 2012-10-19T18:22:02.843 回答