- 公司开源节流的大背景下 我们需要节省成本
- PHP7相对于现在魅族线上的PHP版本5.X 性能提升至少一倍以上
- 社区日活用户增长迅速(15年数据 日均PV 年增长348% 日均UV年增长112%)
- 移动互联网的大环境下 要求我们的程序能够更快的速度响应用户的请求 以满足更好的用户体验
- 对新技术的求知欲望(满足自己的一点点虚荣心)
PHP5.1 5000个数快速排序平均响应时间2587ms
PHP5.2 5000个数快速排序平均响应时间2625ms
PHP5.3 5000个数快速排序平均响应时间2509ms
PHP5.4 5000个数快速排序平均响应时间2339ms
PHP7.0 5000个数快速排序平均响应时间685ms
PHP5.1 WordPress平均响应时间505ms
PHP5.2 WordPress平均响应时间521ms
PHP5.3 WordPress平均响应时间498ms
PHP5.4 WordPress平均响应时间470ms
PHP7.0 WordPress平均响应时间158ms
PHP5.4 500个数快速排序TPS 552
PHP7.0 500个数快速排序TPS 3165
Flyme社区APP首页 PHP5.4 TPS 1535
Flyme社区APP首页 PHP7.0 TPS 1975
Flyme社区APP板块列表页 PHP5.4 TPS 2237
Flyme社区APP板块列表页 PHP7.0 TPS 2387
1. JIT
2. Zval的改变
3. 内部类型zend_string
4. PHP数组的变化(HashTable和Zend Array)
5. 函数调用机制(Function Calling Convention)
6. 通过宏定义和内联函数(inline),让编译器提前完成部分工作
- 实际的业务不一定有很复杂的计算逻辑
- 实际的业务会用到Redis 和MYSQL,网络和IO的瓶颈 影响了PHP7的整体性能
- HTTPS的性能问题 限制了PHP7的能力
Redis Proxy目的是为了做Redis高可用&分布式缓存用的
经过性能测试,相对直接连接redis而已,用Proxy的性能损耗在10-15%左右(不同的业务 可能影响有比较大的差异)
那么Proxy是不是还有优化的空间的呢?
PHP和Redis长短链接的问题PHP7 Redis长连接比短连接性能高10%左右(不同的业务差别比较大)
MYSQL数据库连接池的问题数据库连接池负责分配、管理和释放数据库连接,它允许应用程序重复使用一个现有的数据库连接,而不是再重新建立一个。
Atlas 是360开发和维护的数据库中间件。是一个位于应用程序与MySQL之间,它实现了MySQL的客户端与服务端协议,作为服务端与应用程序通讯,同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节,同时为了降低MySQL负担。
Atlas 支持主库宕机不影响读、读写分离、自动分表、安全处理、平滑重启、连接池等
用了数据库连接池后 TPS性能杠杠的 整整提高了80%
来看看效果吧
- PHP是解释型语言,Zend引擎会将PHP代码解释为可执行机器码(Operate Code)之后再交由CPU执行。
Opcache是如何加速的
看看加了opcache后的成果吧(请求平均响应时间足足减少了一倍 有木有)
PGO是一项编译优化技术,它可以配合GCC等编译器使用,提高编译器的编译效率。
虽然PGO可以提高编译效率,但它并没有被广泛使用。
原因很简单:
1. 它繁杂的双编译模型 和 有限的使用场景,让PGO显得很鸡肋
2. 在有了opcache这样的产品出现后,PGO带来的性能提升并不是很明显。
<source lang="xml" collapse="false" first-line="1"> #php-fpm.conf listen = /dev/shm/php-fcgi.sock #php-fpm2.conf listen = /dev/shm/php-fcgi2.sock #/usr/local/php/sbin/php-fpm --fpm-config /usr/local/php/etc/php-fpm.conf #/usr/local/php/sbin/php-fpm --fpm-config /usr/local/php/etc/php-fpm2.conf #代理 upstream backend{ server unix:/dev/shm/php-fcgi.sock; server unix:/dev/shm/php-fcgi2.sock; } </source>
HugePage(提升2%-3%)
默认的内存是以4KB分页的,而虚拟地址和内存地址是需要转换的, 而这个转换是要查表的,
CPU为了加速这个查表过程都会内建TLB(Translation Lookaside Buffer), 显而易见如果虚拟页越小,表里的条目数也就越多,
而TLB大小是有限的,条目数越多TLB的Cache Miss也就会越高, 所以如果我们能启用大内存页就能间接降低这个TLB Cache Miss。
<source lang="xml" collapse="false" first-line="1"> opcache.huge_code_pages=1 sudo sysctl vm.nr_hugepages=128 </source>
相性能参数优化
php.ini配置
<source lang="xml" collapse="false" first-line="1"> opcache.enable=1 opcache.enable_cli=1 opcache.memory_consumption=128 opcache.interned_strings_buffer=8 opcache.max_accelerated_files=4000 opcache.revalidate_freq=60 opcache.save_comments=0 opcache.fast_shutdown=1 opcache.huge_code_pages=1 opcache.file_cache=/dev/shm/opcache/ </source>
PHP-FPM
<source lang="xml" collapse="false" first-line="1"> listen = /dev/shm/php-fcgi.sock pm = static pm.max_children = 320 pm.max_requests = 10240 </source>
Nginx HTTPS的性能问题
研究PHP7技术的背景- 公司开源节流的大背景下 我们需要节省成本
- PHP7相对于现在魅族线上的PHP版本5.X 性能提升至少一倍以上
- 社区日活用户增长迅速(15年数据 日均PV 年增长348% 日均UV年增长112%)
- 移动互联网的大环境下 要求我们的程序能够更快的速度响应用户的请求 以满足更好的用户体验
- 对新技术的求知欲望(满足自己的一点点虚荣心)
相关学习视频分享:php视频教程
以上就是一分钟了解PHP7性能的蜕变(性能提升4倍)的详细内容,
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)