首先,后端外围资源,是指跟 PHP 运行过程中与语言本身无关的网络与 IO 操作、存储服务、中间件代理、缓存和数据库访问等,在本文中,我们先分析 IO 操作和中间件服务。
为什么外围资源的性能分析,要以以上三者分析为主?我们可以看如下国内专业的性能监控工具 OneAPM 的 PHP Web 应用后台截取下来的总览图,通过这个图可以看到,数据库所花费的时间在总 PHP 响应时间中,占据着 60% 甚至更大的比重,而 Memcached 缓存服务,在这张图里所占的响应时间,几乎看不见。
PHP 语言本身尽管有性能的差异,但是从对 PHP 的性能微观分析也可以看出,如果只执行单次操作,实际中这种差别是非常小的,前面的实验中,十万次以上操作,才有百 ms 级的差别,因为 PHP 语言本身操作的是内存,一次内存访问,大约在 50ns 左右。而 IO 操作,则是磁盘访问,一次磁盘访问所费时间在 5ms 以上。仅从这个数量级看是 10 万倍的差距,实际上,根据实验,也有百倍级的差距(顺序访问和随机访问差距巨大,实际中两者同时进行,还会有磁盘缓存等)。
所以对比语言本身,IO 成为瓶颈的可能性更大。首先看一下,IO 操作带来的性能差别。
一个 PHP 脚本,通过 PHP 命令方式运行,正常时,消耗时间如下:
当使用如下命令清空磁盘缓存后:
echo 3 | sudo tee /proc/sys/vm/drop_caches
代码一模一样,但是运行时间却是正常运行时间的 6 倍。当然这个时间的慢,并不仅仅是由于程序本身的 IO 操作导致,而更大的慢的因素是在 CGI 模式下,PHP 脚本的每一次运行都需要加载所有模块,这个加载,也伴随着大量的 IO 操作。
再做一个实验,完全同样功能的两个页面,一个采用了 MVC 的方式,把头部,尾部拆开成独立的模板(并未使用模板引擎),中间逻辑也使用独立的 Model 类来处理。另一个只 require 了宏定义和数据库操作两个文件。
使用命令ab -c 40 -n 1000 http://xxxxx/0929/zuche/carlist.php 进行压力测试, 这两个页面运行稳定后压测结果数据。
在这个页面中,MVC 版本所费时间要多 6-8ms 左右。虽然只是多增加了几个文件包含,但是明显增加了请求延时,如果文件操作本身更加复杂,比如文件上传、检测、转换,则延时会增加一个数量级以上。在实际的生产使用中,也不是说有了文件操作,就一定会产生大的延时,因为就像本例的 require 而言,由于磁盘缓存等的存在,延时的影响已降低很多。
在正式使用中间件之前,我们先对比一下,使用数据库与不使用数据库的差别,同样是上面的这个例子,我们把数据结果集,从数据库获取转换成为直接的结果数组设置,为了结构化清楚,采用 MVC 这一版。同时为了更显著对比上一轮测试结果,同时也消除语言本身的一些慢的因素,在本轮实验中,我们采用 PHP7,得到结果是令人吃惊的。 如下图是带有数据库连接和数据读取的版本,PHP 扩展使用的是 mysqli。
由于本页面,只有一次数据库操作,页面结构也比较简单,语言本身的影响因素非常大,PHP7 下速度有两倍以上提升,原来平均响应时长为 37-40ms,现在则为 14ms。
即使如此,不读取数据库时,有 4ms 的差距,尽管数目上不大,但是对于一个总响应时长只有 14ms 的应用,这 4ms 已经很显著了,而这只是一个数据库查询操作。
接下来看一下,当增加一层数据库中间件时,效率又有怎么样的变化呢?由于笔者所使用的中间件,目前并不支持 PHP7,所以我们还在老版 PHP 的基础上来比对。在同样的服务器压力下,使用了中间件的版本慢了一倍以上。
从这个例子可以看出来,原本 PHP 直接连数据库,取得数据的操作,增加了中间件之后,变了先到中间件,中间件再到数据库,返回亦如是,导致了速度的大幅度下降(这里已经剔除了中间件本身占用资源的因素,在原来直连的版本是 37-40ms 左右)。
这里也请读者不要误解,演示中间件使用速度下降的例子,并不是说为了说明中间件不好,在分布式环境下,使用中间件是非常必要的。而是说,程序的外部资源,往往是影响性能的重要因素,尤其是当外部资源的连接和数据获取本身速度达不到理想的结果时。
对于 IO 操作和中间件服务的分析就到这里,下篇将分析数据库给整个应用性能带来的影响。