我刚注意到我的应用程序在一个页面上包含超过148个php文件。请记住，这是后端管理员而不是主站点，但是这个太多了吗？大量的包含对服务器有什么影响，既有平均负载又有压力？磁盘I / O会出问题吗？
文件类型 - 包括计数 - 组合文件大小
时间已经 0.123920917511
使用内存 2.891 MB
编辑1。应该注意，这是最糟糕的情景页面。它有许多不同的模板模型，控制器和相关视图，因为它处理使用自定义字段的发布。
编辑2。此外，前端还具有强大的页面缓存功能，因此前面包含的内容大约为30-40。
编辑3。关闭时，Profiler不会包含文件，所以这会减少相当多的包含
答案 0 :(得分：4)
所以，这是潜在问题的细分。
文件数量本身就是一个问题。除非您使用字节码缓存（并且是），并且在提取已编译的字节码之前将该缓存配置为不统计文件，否则PHP将统计这些文件中的每一个在包含，然后读取它们。在某些情况下，这也可能意味着路径解析和一个天真的自动加载器，在许多目录戳戳和刺激。这不会“慢”，因为如果文件被频繁命中，操作系统肯定会有缓存的东西，但它确实为每个请求添加了宝贵的毫秒数。
如果每个自动加载器设计正确和，代码库完全依赖自动加载器来引入所需的类（意味着没有在类文件中使用include / require / include_once / require_once），您可以避免必须通过将每个类粘合在一起形成一个大的包含来打开和读取许多文件。这有点不切实际，主要是因为如果没有字节码缓存，PHP仍然需要解析，编译和解释它们。此外，并非每个类都会在每个请求中使用，因此可能有点浪费。
最重要的是，配置良好的字节码缓存将完全缓解此问题。告诉客户他们必须正确配置服务器以获得最佳性能并没有错。如果他们知道自己在做什么，他们就会把所有事情都弄清楚。
答案 1 :(得分：2)
是，这么多文件可能会有问题。
否，在您的情况下可能不是问题，因为这只是一个后端，可能是少数人访问的，而不是常。
一般情况下，我不鼓励在每个页面上调用超过20个PHP文件。这是因为即使网站和服务器都经过高度优化，对于每个页面，服务器必须查看每个文件，以便至少看到自上次请求后是否发生了更改（如果此级别没有实现缓存）。 / p>
即使访问文件的时间很短，也是您在每次请求时丢失的时间。这个微小的时间乘以148可能成为一个问题（并且是一个巨大的可扩展性问题）。
当我处理PHP框架项目时，我使用了一个技巧来减少文件数量。将几个文件合并为一个缩小文件，并缓存此单个文件。然后，如果需要更新框架或网站，则会自动删除缓存的文件，然后重建。
即使我个人不鼓励你缩小源代码（因为它很难做，难以测试，并且会产生一堆问题，比如错误中无意义的行数），你可能会做同样的事情将所有文件合并到一个文件中。
注意：如果页面A使用这些文件的一半，而页面B使用另一半，那么组合所有内容可能会降低性能，因为PHP引擎必须解析更多代码。
答案 2 :(得分：1)
包含自己是否做了一些奇特的事情，比如数据库查询？它们都在页面顶部，还是根据需要包含在内？
这些统计数据看起来并不糟糕，因此，如果管理员访问不常见，您可能没问题。但是你应该从设计的角度来研究这个问题：事情是否可以以一种阻止你不得不维护这么多包含的方式进行组织？与任何性能问题分开，存在创建难以跟踪的依赖性错误的风险。
（可能是MainMa说的，与框架相关，在这种情况下，你可能无法控制上述情况。我只会提到它。）
如果您还不知道，还有几件事：
答案 3 :(得分：0)
磁盘I / O不是你的问题。系统会将频繁访问的文件缓存在RAM中，或者如果它们不经常访问，则无关紧要。
加载时间可能是个问题，因为服务器必须单独请求和解释每个文件。
我不知道网络服务器将如何处理许多请求;它可能不在乎。如果客户端不执行流水线请求，您将支付许多建立和拆除的TCP连接，这也会花费大量的延迟。
答案 4 :(得分：0)
老实说，不要担心它 - 148什么都不是，即使在php端发生了0缓存，你几乎每次都会遇到fs缓存 - 并且在事物的宏伟计划中几乎每个开源都有更多文件没有问题（drupal，wordpress，joomla，elgg，任何东西）。
真的，这里没问题 - 即使你设法在这里或那里刮掉一毫秒，它仍然是优先级列表中的优势列表和你可以提速的地方，它几乎不值得考虑超过一秒钟。
警告：尝试在适当的地方使用require_once和include_once，并确保只加载给定请求处理所需的类/文件。