php – 148包含的文件太多了

发布时间：2020-12-13 21:37:48 所属栏目：PHP教程来源：网络整理

导读：我刚注意到我的应用程序在一个页面上包含超过148个php文件.请记住,这是后端管理员而不是主站点,但是这个太多了吗？大量的包含对服务器有什么影响,既有平均负载又有压力？磁盘I / O会出问题吗？包含的文件统计信息文件类型 – 包括计数 – 组合文件大小索

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

包含的文件统计信息

文件类型 – 包括计数 – 组合文件大小

>索引 – 1 – 0.00169 MB
> Bootstrap – 1 – 0.01757 MB
>助手 – 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.应该注意,这是最糟糕的情况页面.它有许多不同的模板模型,控制器和关联视图,因为它处理使用自定义字段的发布.

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

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

解决方法

所以,这是潜在问题的细分.

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

如果每个自动加载器设计正确并且代码库完全依赖自动加载器来引入所需的类(意味着在类文件上没有使用include / require / include_once / require_once),则可以避免打开和读取许多文件将每一个类别粘合在一起构成一个大的包含.这有点在不切实际的方面,主要是因为如果没有字节码缓存,PHP仍然需要解析,编译和解释它们.此外,并非每个类都会在每个请求中使用,因此可能有点浪费.

最重要的是,配置良好的字节码缓存将完全缓解此问题.告诉客户他们必须正确配置服务器以获得最佳性能并没有错.如果他们知道自己在做什么,他们就会把所有事情都弄清楚.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!