php - 148 是不是包含的文件太多

Question

我刚刚注意到我的应用程序在一个页面上包含超过 148 个 php 文件。请记住，这是后端管理员而不是主站点，但这太多了吗？在平均负载和压力下，大量包含对服务器有什么影响？磁盘 I/O 会成为问题吗？

包含的文件统计信息

文件类型 - 包含计数 - 组合文件大小

• 索引 - 1 - 0.00169 MB
• Bootstrap - 1 - 0.01757 MB
• Helper - 98 - 0.58557 MB -(11 个是 Profiler 相关类)
• 配置 - 8 - 0.00672 MB
• 数据存储 - 23 - 0.10836 MB
• 操作 - 8 - 0.02652 MB
• 第 1 页 - 0.00094 MB
• I18n 资源 - 7 - 0.00870 MB
• 供应商库 - 1 - 0.02754 MB
• 文件总数 - 148 - 0.78362 MB

运行时间 0.123920917511

已用内存 2.891 MB

---

编辑 1. 应该注意，这是最坏情况的页面。它有许多不同的模板模型、 Controller 和关联 View ，因为它处理自定义字段的发布。

编辑 2. 此外，前端具有激进的页面缓存，因此目前前端的包含数量大约为 30-40。

编辑 3. Profiler 关闭时不会包含文件，因此这将减少相当多的包含

Answer 1

因此，这是对潜在问题的分割。

文件数量本身就是一个问题。除非您正在使用字节码缓存(而且您确实在使用)，并且该缓存被配置为在拉入编译后的字节码之前不统计文件，否则 PHP 将对这些文件中的每一个进行统计on include，然后读入它们。在某些情况下，这也可能意味着路径解析和一个天真的自动加载器，它会在许多目录中戳和戳。这不会很“慢”，因为如果文件被频繁访问，操作系统肯定会缓存一些东西，但它确实会为每个请求增加宝贵的毫秒数。

如果每个自动加载器都设计得当并且代码库完全依赖于自动加载器来拉入所需的类(意味着没有在类文件上使用 include/require/include_once/require_once)，你可以避免必须通过将每个类粘合到一个大的包含中来打开和读取许多文件。这有点不切实际，主要是因为如果没有字节码缓存，PHP 仍然要全部解析、编译和解释。此外，并非每个类都将用于每个请求，因此可能有点浪费。

底线是配置良好的字节码缓存将完全缓解这个问题。告诉您的客户他们必须正确配置他们的服务器以获得最佳性能并没有错。如果他们知道自己在做什么，他们就会从一开始就知道一切都是正确的。