包含 PHP 文件对性能有多大影响？

Question

问题几乎说明了一切，我正在开发一个大型项目，其中大多数对 php include() 的调用在 100 到 150 个文件之间。 php 平均花费的时间在 150 到 300 毫秒之间。我想知道其中有多少是由于包含 PHP 脚本造成的？我一直在考虑运行一个脚本来检查最常访问的文件中的特定调用，并将它们合并到一个文件中以加快速度，但据我所知，这影响为零。

我应该注意，我使用 APC，我不完全了解 APC 在后台做什么，但我想它可能已经以某种方式缓存了我的文件，因此文件数量并没有真正产生很大的区别？

非常感谢有关该主题的任何意见。

当然，300 毫秒并不算多，但如果我能把它降低到 100 甚至 50 毫秒，那就是一个显着的提升。

编辑：

为了澄清我正在谈论通过 php include / require 加载文件。

Answer 1

文件加载是一件棘手的事情。正如其他人所说，唯一可靠的判断方法是进行一些基准测试。但是，这里有一些一般规则仅适用于 PHP 加载，不适用于使用 fopen 的文件：

• APC 会将其操作码缓存存储在共享内存中，因此您将在第一次加载时受到影响，但不会在后续加载时受到影响。
• include 和 include_once （以及它们的 require 表兄弟）实际上相当重。以下是一些提高速度的技巧：
  • 使用文件的绝对路径（避免像 ../foo.php 这样的相对路径）
  • 两个 _once 函数都需要进行检查，以确保该文件不是通过符号链接包含的，因为符号链接可以生成同一文件的多个路径。这是非常昂贵的。 （参见下一点）
• 仅加载所需的文件比调用 include 便宜得多。使用自动加载器仅在需要时加载类。
• 本地磁盘几乎总是比网络存储更好的选择。如果可能，如果您有多个服务器，请在每台服务器上保留源代码的副本。这意味着您需要在发布期间更新多个位置，但在性能方面付出的努力是值得的。

总的来说，这取决于您的硬盘速度。但与根本不加载文件或从 RAM 加载文件相比，文件加载速度慢得令人难以置信。

我希望这有帮助。

Answer 2

这是相当多的文件，但如果使用框架（Zend 可能吗？），这并不意外。包含这么多文件的影响主要取决于服务器硬盘的速度。无论如何，文件访问速度非常慢，因此如果可以的话，请减少包含的数量。

不过，APC 确实/可以在内存中缓存所有这些文件的操作码，这意味着在缓存失效/销毁之前不会再进行磁盘查找。

• 尝试关闭 APC，看看它会产生多大的变化。执行时间应该会出现明显的峰值。

• 尝试使用 xdebug 分析脚本。您很可能会发现还有其他问题（代码问题）比文件访问对性能的影响更大。

Answer 3

我知道这是一个非常老的问题，但我也想知道同样的事情，谷歌把我带到了这里。我最终使用 PHP 7.4（现已停产）在一台小型通用 Digital Ocean 服务器（配有 SSD 驱动器）上进行了一些基准测试。

方法：

我创建了 260 个类，每个类都有自己的文件。文件的名称类似于 A0.php、A1.php、A2.php、...、Z8.php、Z9.php。它们只有 608 字节，很小，因此在读取结果时请记住这一点。

我还创建了一个文件，LotsOfClasses.php，其中包含所有 260 个类。该文件大小约为 155k。

脚本从命令行运行，没有 PHP 缓存。人们应该假设底层 CentOS 操作系统的磁盘缓存正常工作。

下面是测试脚本的基本样子（选择 microtime 而不是 hrtime，因为它更容易被人类阅读）：

<?php
$start = microtime(true);
foreach (range('A', 'Z') as $letter) {
    foreach (range(0, 9) as $i) {
        include "{$letter}{$i}.php";
    }
}
echo (microtime(true) - $start) . "\n";

然后

<?php
$start = microtime(true);
include "LotsOfClasses.php";
echo (microtime(true) - $start) . "\n";

我以 100 为一组运行每个脚本 3 次：

for i in {1..100}; do php benchmark.php; done > time.txt

我还编写了一个脚本来计算平均值。没什么特别的，但为了完整起见，将其包含在此处：

<?php
$file = file_get_contents("time.txt");
$values = array_filter(explode("\n", $file));
echo (array_sum($values) / sizeof($values)) . "\n";

命令行结果：

包含 1 个包含 260 个类的文件所需的平均时间为 11.79 毫秒。

包含 260 个文件（每个文件属于一个类）所需的平均时间为 21.42 毫秒

Web 服务器结果：

精明的读者可能会问，包含大约 155k 的单个文件为何需要 11.79 毫秒。这是否意味着如果您的应用程序加载了 100 个此类文件，则仅包含文件就需要 1 秒以上的时间？如果使用命令行，答案是肯定的。然而，PHP 通常通过服务器运行。当在命令行上运行时，PHP 每次都必须解析该文件。通过服务器加载文件时，PHP 将使用其 Opcache，速度明显更快。

包含 1 个包含 260 个类的文件所需的平均时间为 0.056 毫秒。

从 Web 服务器包含 260 个文件所需的平均时间为 0.65 毫秒。

结论：

虽然 1 个大文件几乎是瞬时的，但通过 Web 服务器加载时，1 个文件和 260 个小文件之间仅存在 0.6 毫秒的差异。增加的幅度可以忽略不计，合并文件很大程度上只是一种微观优化。即使在更大的应用程序中，我也无法想象它的差异会超过几毫秒。此外，单个文件的维护可能会更加复杂。我想说，加载多个可维护文件来换取微不足道的时间增加是值得的。

无论如何，我还在 Web 服务器上尝试使用 260 文件版本的 include_once ，它只增加了 0.08ms 的时间。