本文为 虚伪的灵魂 版权所有, 禁止任何商业网站转载, 个人博客转载请于文章起始位置标明 “转载自 使用 strace 测试 Yii 2, Laravel 5, Phalcon 框架性能 – 虚伪的灵魂“.
一. 前言
最近在使用 Laravel, 公司项目上线后, 性能表现不尽如人意, 因为这样的情况, 才促使我去做这样一件测试框架性能的事情. 在朋友的提醒下, 我开始鼓捣起了 strace. strace 是用来追踪进程执行过程中对硬件操作(比如硬盘)时产生的系统调用和所接收的信号的. 本文中所用到的参数很简单, 就是 -c . strace -c
用来统计 php-fpm 在整个执行过程中的各种系统命令的调用数量以及耗时情况. 这已经能在很大程度上判别出一个框架的性能了.
二. 测试设计
- 测试对象: 原生PHP, Yii 2, Laravel 5.1 以及 Phalcon 2.
- 测试内容1: 测试对象以最快方式输出 “Hello, XXX”, 为了避免初始化的问题, 从第二次起开启 strace 性能追踪, 为避免单次误差, 所以性能追踪连续统计10次.
- 测试内容2: 在开启 Zend OPCache 的情况下, 再次完成上述测试, 以理解 OPCache 带来的性能提升, 但是OPCache 是存在内存限制的, 因此每次测试前都会重启 PHP-FPM 进程.
三. 测试代码
a. 原生PHP
b. Yii 2
新装好 Yii 2, 建立项目后直接修改默认控制器SiteController代码:c. Laravel 5.1
新装好 Laravel 5.1 后, 直接修改 routes.php 文件d. Phalcon 2.
入口脚本registerDirs(array( '../app/controllers/', '../app/models/' ))->register(); $di = new FactoryDefault(); $di->set('view', function(){ $view = new View(); $view->setViewsDir('../app/views/'); return $view; }); $di->set('url', function(){ $url = new UrlProvider(); $url->setBaseUri('/tutorial/'); return $url; }); $application = new Application($di); echo $application->handle()->getContent(); } catch(\Exception $e) { echo "PhalconException: ", $e->getMessage(); }默认控制器 IndexController:
四. 第一轮测试, 无 Zend OPCache
a. 原生测试结果:
b. Yii 2 测试结果:
C. Laravel 测试结果:
Laravel 第一轮第1次, 直接执行:
Laravel 第一轮第2次, 在执行过 composer dumpautoload --optimize 后:
Laravel 第一轮第3次, 在执行过 php artisan optimize --force 后:
五. 第一轮试验总结:
- 原生还是快的
- Laravel 没做优化速度简直感人
- Laravel 做完优化速度提升简直感人(自己体会两个感人
- 优化过的 Laravel 居然比 Yii 2 跑的快...颠覆了我的认知
- Phalcon 2 毫无悬念的在性能上完爆了 Yii 2 和 Laravel. 完全不通的数量级啊.
- 另外需要注意的是, 结果是执行10次总的统计数量.
六. 第二轮测试, 有 Zend OPCache.
a. 原生测试结果:
b. Yii 2 测试结果:
C. Laravel 测试结果:
D. Phalcon 测试结果:
七. 第二轮试验总结:
- 原生还是快.
- Yii 2 性能上胜过了 Laravel.
- Phalcon 2 再次毫无悬念的在性能上完爆了 Yii 2 和 Laravel.
八. 试验总结:
- 未做 artisan optimize 的 Laravel 性能很差.
- OPCache 后的 Yii 2 性能才能胜过 Laravel.
- Phalcon 2 性能刚刚的毕竟是扩展级的.
- 只要有 PHP 文件就有, OPCache 都有优化的空间(好大一句废话).
九. 测试的不足之处
strace 只能追踪到进程针对硬件的调用, 程序内部的运算对CPU的占用及消耗, 并不能很好的体现出现出来. 比如框架本身存在如果比较大的运算量, 比如正则运算, 并不能很好的体现出来.
十. 思考
- Composer 在提供了便利安装依赖的同时是不是增加了性能的负担呢?
- Composer 依赖少的时候可能性能并不明显, 而依赖多的时候呢?
请问博主,贵公司在使用phalcon后是否满足了需求呢?
并发达到了多少?
主要决策是开发速度与服务器响应能力的取舍.
之前做这个对比的时候线上的项目并没有替换成Phalcon, 使用Laravel只能勉强满足支撑需求, 具体数据不便透露
之后, 对Phalcon做了一个简单的二次封装 效率比Laravel高了不少, 开发速度也不算慢.
就是这样..
博主
1、Laravel,在开启性能优化之后,对贵司项目的性能是否到达要求了?
2、为什么没有使用Phalcon框架呢?
1. 没有
2. 现在在用 Phalcon
Composer依赖多了纯粹依靠composer dumpautoload –optimize把复杂的autoload变成了一个文件式查找,变的再大也就是一个数组查找
文件依赖数量还是大, 要做很多底层的文件状态检测