PHP中我们了解了那么多关于php7的知识，不知道你们对php7有多少了解，我相信很大一部分人会不知道这部分知识点，那么不急本篇文章就是带领大家更深刻的去了解这个内容。
研究PHP7技术的背景
- 公司开源节流的大背景下 我们需要节省成本
- PHP7相对于现在魅族线上的PHP版本5.X 性能提升至少一倍以上
- 社区日活用户增长迅速（15年数据 日均PV 年增长348% 日均UV年增长112%）
- 移动互联网的大环境下 要求我们的程序能够更快的速度响应用户的请求 以满足更好的用户体验
- 对新技术的求知欲望（满足自己的一点点虚荣心）
PHP7性能小记
PHP7性能初印象（比PHP5提升3倍＋）
1. 性能对比 - 快速排序算法（随机生成5000个数后按照快速算法排序）
PHP5.1 5000个数快速排序平均响应时间2587ms
PHP5.2 5000个数快速排序平均响应时间2625ms
PHP5.3 5000个数快速排序平均响应时间2509ms
PHP5.4 5000个数快速排序平均响应时间2339ms
PHP7.0 5000个数快速排序平均响应时间685ms
2.性能对比 - WordPress首页
PHP5.1 WordPress平均响应时间505ms
PHP5.2 WordPress平均响应时间521ms
PHP5.3 WordPress平均响应时间498ms
PHP5.4 WordPress平均响应时间470ms
PHP7.0 WordPress平均响应时间158ms
3.性能对比 - Flyme社区APP
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
性能测试遇到的几个问题&解决办法
为什么PHP7的性能可以提高这么多？
1. JIT
2. Zval的改变
3. 内部类型zend_string
4. PHP数组的变化（HashTable和Zend Array）
5. 函数调用机制（Function Calling Convention）
6. 通过宏定义和内联函数（inline），让编译器提前完成部分工作
立即学习“PHP免费学习笔记（深入）”；
为什么PHP7的在实际的业务性能提高才30%左右？
- 实际的业务不一定有很复杂的计算逻辑
- 实际的业务会用到Redis 和MYSQL，网络和IO的瓶颈 影响了PHP7的整体性能
- HTTPS的性能问题 限制了PHP7的能力
Redis Proxy的问题
Redis Proxy目的是为了做Redis高可用&分布式缓存用的
经过性能测试，相对直接连接redis而已，用Proxy的性能损耗在10-15%左右（不同的业务 可能影响有比较大的差异）
那么Proxy是不是还有优化的空间的呢？
PHP和Redis长短链接的问题
PHP7 Redis长连接比短连接性能高10%左右（不同的业务差别比较大）
MYSQL数据库连接池的问题
数据库连接池负责分配、管理和释放数据库连接，它允许应用程序重复使用一个现有的数据库连接，而不是再重新建立一个。
Atlas 是360开发和维护的数据库中间件。是一个位于应用程序与MySQL之间，它实现了MySQL的客户端与服务端协议，作为服务端与应用程序通讯，同时作为客户端与MySQL通讯。它对应用程序屏蔽了DB的细节，同时为了降低MySQL负担。
Atlas 支持主库宕机不影响读、读写分离、自动分表、安全处理、平滑重启、连接池等
用了数据库连接池后 TPS性能杠杠的 整整提高了80%
来看看效果吧
sdxShop是一款完全开源免费的网上独立建店系统，asp+access，程序经过专业团队开发升级发展了7年，功能和安全性已经达到非常成熟稳定，安装容易，一分钟就可以搭起专业的电子商务网站。该免费版功能完整永久免费，主要特色功能淘宝数据表导入，实现网店和淘宝网店数据统一，拓展网店经营策略，提供5种在线支付接口等等。
PHP7性能优化的几个细节
PHP7 Opcache（提升1倍左右）
Opcache的工作原理 ？
- PHP是解释型语言，Zend引擎会将PHP代码解释为可执行机器码（Operate Code）之后再交由CPU执行。
Opcache是如何加速的
看看加了opcache后的成果吧（请求平均响应时间足足减少了一倍 有木有）
编译器GCC4.8+PGO（提升5%-10%）
PGO是一项编译优化技术，它可以配合GCC等编译器使用，提高编译器的编译效率。
虽然PGO可以提高编译效率，但它并没有被广泛使用。
原因很简单：
1. 它繁杂的双编译模型 和 有限的使用场景，让PGO显得很鸡肋
2. 在有了opcache这样的产品出现后，PGO带来的性能提升并不是很明显。
开启多个PHP-FPM主进程（提高10%左右）
<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部分性能参数优化
-
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视频教程
