PHP spl_autoload_register 会影响多少性能?

[sayitagain]

项目现在东西多了引用的类也比较多了,目前考虑用 spl_autoload_register 统一下引用,现在线上直播大约可以承载规模 5w 人次的同时访问量,就想知道 spl_autoload_register 这玩意儿有没有人实际测过会对访问性能产生多少影响?还是可以忽略?看很多开源框架都是用这个,应该也有它的道理吧?

[shoaly]

换个思路, 弄一下 阿里云的负载均衡, 这样你就不慌了, 哪怕有一天 5w 变成 8w 遭不住的时候 , 可以直接开个机器 瞬间翻倍访问量, 然后慢慢去研究怎么 让单机 8w 变成 18w

[sayitagain]

@shoaly
直播 centos7 x64 物理机 16C 32G
centos7 x64 物理机 16C 32G
centos7 x64 物理机 16C 32G
直播 centos7 x64 物理机 32C 64G
缓存 centos7 x64 物理机 16C 32G
DB centos7 x64 物理机 16C 32G

目前这些,就怕上线崩

[shoaly]

那你们 都是托管的么.... 不考虑上云么

[shoaly]

@sayitagain 就是怕上线崩, 一般都用云比较容易 扩展撒

[mshadow]

框架基本都这么用。
可以把一些动态查找类文件的逻辑改一下，
比如预先生成 类名=>类路径 的 kv 数组，然后直接从数组里面取

[jfcherng]

不用 composer 麼... -a 自動生成 class map

[liuxu]

嗯。。理论上来说，使用自动加载能提升性能。。有个词叫”惰性加载“，首先说说 php 内核新建类的原理

php 运行时内核有一个 EG(class_table)全局变量，里面保存了你所有的类信息

当我们用 require_once 引入类文件，php 在运行脚本的时候，首先会解析引入的类文件，添加到 EG(class_table)中，这样你新建类的对象时，会从 EG(class_table)找到相应的类信息

但你用自动加载而不是 require_once 后，php 在运行脚本时，由于没有引入类文件，所以开始没有对应的类文件解析过程，EG(class_table)里面也没有你的类文件。这时你新建类的对象，从 EG(class_table)里面找不到类，php 会调用自动加载程序，然后加载你的类文件解析添加到 EG(class_table)中，然后新建对象

所以对比来看：
使用 require_once:
1.加载解析引入的类文件，添加到 EG(class_table)
2.解析当前文件
3.新建使用对象
4.释放资源

使用 spl_autoload_register：
1.解析当前文件
2.新建使用对象
3.没有找到对象，调用 spl_autoload_register 加载类文件，解析类文件，添加到 EG(class_table)
3.新建使用对象
4.释放资源

可以看到，缩短了 php 内核持有类的时间
当然，spl_autoload_register 执行也需要消耗 CPU 资源，但是如果你加载的类文件很多很大，spl_autoload_register 那点资源就不用算上了

[liuxu]

一楼大佬，不敢评价

不知道楼主的 5w 是如何计算的，没有具体架构和配置信息不好评价

如果 5W 观看直播的用户，每人 200KB/s 的流量，也就 10GB/s 输出流量，想必是用的阿里直播服务，而不是自己搭建直播服务器

抛开直播业务，单说普通的 CURD
1.5W 中多少可以交给 CDN
2.回源到 nginx 的流量是多少
3.到 php 的动态请求有多少
4.缓存命中多少
5.php 到 mysql 读库有多少，php 到 mysql 写库有多少

就我的经验，压力在写库难以横向扩展，只能分库分表，其他的可以加机器改配置解决

[sayitagain]

@liuxu 都是大佬好专业,这两天试了下用 spl_autoload_register ,目前来看...好像没啥变化,影响较小,几乎没有影响...业务是对公的,客户方面的自建机房,网络和配置都很高(公家的东西..钱不是问题)

[liuxu]

@sayitagain 羡慕

[zooeys]

目前来说 spl_autoload_register 不会成为你的性能瓶颈...... 改好一个 sql，用好一个缓存，可能性能都提升无数倍了