PHPCon China 2016 概要

1、 信海龙·《PHP系统问题排查实践》

PHP系统常见问题形式

502 Bad Gateway

  • php-fpm占满
  • 报错信息不应该出现nginx版本的信息,黑客会根据相应的版本号,找到漏洞攻击。比如说[nginx文件路径处理远程命令执行漏洞`](http://edu.cnzz.cn/201303/867622f9.shtml)。应该跳转到自定义的错误页面。

mysql_connect():xxxxxxxxxxxxx too many connections in /opt/wwwroot/xxxxxxx.php on line xx

  • 大并发占满mysql连接,出现报错信息
  • 报错信息出现:
    • 使用的mysql扩展,有被sql注入风险
    • 出现磁盘路径
  • 处理:
    • 增加mysql最大连接数
    • 使用连接池技术
    • 自定义错误页面

[20-Dec-2014 21:20:17] WARNING: [pool www] child 31401 said into stderr: "NOTICE: PHP message: PHP Warning: PDO::__construct(): MySQL server has gone away in ./abstract.class.php on line 26"

解决问题的基本思路

第一步: 恢复服务、保留现场

恢复服务,不能影响线上业务。

保留现场,方便排查问题。

  • 运行状态
    • 有问题时的状态数据
  • 外部监控
    • 第三方监控数据
  • 系统日志
    • 系统内部日志数据

第二步: 排查问题

排查问题,纠错,修BUG

知识 + 工具 + 数据

知识:
– 语言
– 基本语法,PHP运行机制
– 系统
– 操作系统,软件相关的知识
– 协议
– Tcp协议 Mysql通信协议

工具:
– 系统
– top
– vmstat
– 网络
– tcpdump 抓包
– wireshark 解包
– netstat
– 进程
– gdb
– pstack
– strace

第三步: 验证

验证,解决bug后,验证是否解决。

观后感: 提供了一个基本的解决方案的思路。但是能够解决什么样的问题,就是靠基本知识了。
依靠知识,会敏锐的发现错误的大致方向
依靠工具,可以全面定位错误
依靠数据,可以验证和证实自己的猜想,以及是否解决问题

2、 韩天峰·《PHP7+Swoole开发超高性能后台程序》

大并发最好的解决方案: 基于epoll实现异步IO处理

nginxswoole都是epoll模型

如何实现1W+ QPS

  • IO操作要足够快 或者 异步, 常见的IO操作:Redis、MySQL、CURL、磁盘读写
  • CPU消耗足够少:应用服务器、PHP框架、PHP应用程序

同步阻塞模型

  • 多开进程就能增加处理能力
  • 增加进程会带来额外的进程切换开销

QPS = 耗时ms * 进程数 / 每秒

CPU消耗

(内核耗时 + php-fpm耗时 + php框架耗时 + php程序耗时) * 内核数 / 每秒

比如
内核耗时: 可以忽略
php-fpm耗时: 2ms
PHP框架耗时:10ms
php程序耗时(业务代码): 20ms

那么单核QPS = (0 + 2 + 10 + 20) / 1000 约等于 33QPS
24核QPS = 33QPS * 24 约等于 800QPS

提升性能

  • 使用php7,基本可以提升100%的性能
  • 使用C扩展框架,比如Yaf/Phalcon
  • 使用swoole应用服务器
    • 将部分PHP对象常驻内存,减少传统LAMP架构每次请求创建销毁对象的开销
    • 纯C编写,网络通信引擎和协议解析性能非常强悍。

zend 引擎

  • APC/OpCache只能优化PHP代码编译生成 OpCode的开销
  • OpCode执行构建内存中可用HashTable需要消耗CPU资源(swoole可以解决这点)
  • LAMP每次请求结束会释放掉HashTable,下一次请求再次构建HashTable内存(swoole可以解决这点)

Swoole优势:

  • 大数组、对象、常量等常驻内存,节省大量重复创建销毁的CPU消耗
  • PHP框架的环境路径计算、常量定义、初始化框架、类载入、解析注释语法等操作仅启动时执行一次
  • 业务代码仅剩最干净的请求处理逻辑

Rango推荐

php7 + swoole + Yaf/Phalcon + Redis = 快如闪电

PHP7+Swoole超高性能程序开发实践

  • 短网址服务
    • 3位检验码 + 自增ID(62进制)
    • swoole_http_server + redis 单机性能高达 5W+ QPS
    • 统计设备号、UID、IP、UV、PV、地理位置等信息,为运营部门提供数据
    • 统计逻辑基于Swoole Task功能实现,不影响核心逻辑
  • mysql-proxy
    • 基于swoole_mysql实现,支持php-fpm长连接
    • 后端使用连接池可以有效减少MySQL服务器的连接数。
    • 支持MySQL后端服务路由,php-fpm到MySQL-Proxy只需要建立一个连接,即可向到多台MySQL服务器发送SQL
    • 不支持事务
  • 高性能统计程序
  • 超高性能统计运算程序
    • 使用PHP Array 全内存 存储、计算数据。超大规模读写Redis会成为瓶颈
    • 使用Worker/Task进程实现数据的Map-Reduce
    • 使用PHP的SPL数据结构,性能很好
    • 中间数据可以使用MySQL内存表,汇总计算后删除数据
    • PHP的GC非靠谱,及时unset掉不用的数据,连续运行无内存泄漏

swoole 2.0

支持协程

3、付超群·《PHP在金融股票项目中的应用》

数据准确性

问题:PHP动态语言,弱类型

“0”== 0
“1000”== 1000
false == 0
null == 0
null == false

解决方案:
配置化的validation

问题:浮点

原因: IEEE 754

解决方法:
1. 全部*1000000,bigint -2^63 ~ 2^63-1
2. 字符串化,bcmath/gmp运算

解耦:一切皆接口

问题:

  • 一个方法/类,做了所有事情,既处理数据又提供服务
  • 直接读写数据库

解决方案:
一切皆接口,包括所有后台服务,一个程序只干一件事情

好处:
a. 容灾/多数据源
b. 统一处理
c. 有损服务/降级服务
d. 便于重构

几个性能问题

1、 缓存

  • 高速缓存 VS 大量数据 → redis & ssdb
  • 被动缓存 VS 主动缓存
  • 特殊情况 dailyCache
  • 正向缓存 VS 反向缓存

2、 多个接口,一个功能页面需要请求N个不同数据接口

方案:
kql, 基于yar的自组织合并请求接口

例如:
一个页面请求,foo接口、bar接口、baz接口。三次请求,IO耗时严重。
合并成一个接口,
请求

响应

3、 实时计算

问题:
a. 数据项多 b. 格式复杂 c. 数据量大 d. 计算指标多

需求:
a. 准实时 b. 计算离数据近 c. 方便,尽量少写代码

方案:
选择mongodb

解决:
a.各种榜单
b.汇总/均值
c.map-reduce:基于mongodb服务器端js编程
d除复权:php7高性能运算

lxc容器部署

问题:
模块多,依赖多,环境复杂

容器:
docker:进程容器
lxc:环境容器,docker他爹

方案:
lxc容器部署,git代码发布

复制:
lxc-clone -o ubuntu -n foobar

备份:
tar –numeric-owner -czf ./foobar.tgz /path/to/lxc/foobar

迁移:
tar –numeric-owner -xzf ./foobar.tgz

4、 张凌·《PHP+TSF在起点中文网全新改版中的协程之路》

基础框架:

  • koa: 前后端分离框架
  • swoole:网络通信引擎
  • tsf:业务逻辑协程框架
  • taf:soa后台服务框架

架构:

  • 接入层 NGINX(页面请求koa)、(数据请求TSF)
  • 模板层 KOA
  • 逻辑层 TSF
  • soa服务层 TAF
  • 数据层 MYSQL、REDIS。。。

协程调度:

协程堆栈 需要研究利用splStack

协程 -> async io -> event loop -> …

Web灰度:

几种方式

  • 客户端模型 b/s架构,分发不同版本的客户端
  • 后台模型 接口版本化,调用调用端配合 App/接口架构
  • web模型

几种策略

  • 账号策略
  • 地域策略
  • 独立端策略

5、赖明星·Sys-Schema

mysql4.1 提供 information_schema 数据词典
mysql5.5 提供 performance_schema 性能词典
mysql5.6 默认开启 performance_schema
mysql5.7 提供 sys 系统数据库

sys schema 的组成

sys schema 包含了一些视图、函数和存储过程
sys schema 可以帮助DBA和开发分析定位问题

就好比,linux 中 performance_schema to /proc, and SYS to vmstat。

为什么要用 sys schema
1. performance_schema 数据量太大,mysql5.6有52张表,mysql5.7有87张表。
2. performance_schema 数据太专业
3. 用户需要的是解决问题的答案,而不是一堆数据。

安装
1. set performance_schema=ON
2. MySQL 5.6+
3. MySQL 5.7默认安装

检测是否安装完成

视图

有2种展示形式, 一种便于人们阅读,还有一种便于工具处理。

使用视图

从使用者角度看代价

  • 谁使用了最多资源

  • 大部分连接来自哪里

从资源角度看使用情况

  • 查看哪个文件IO最多

案例

  • 索引统计

  • 索引重复

  • 无用索引

  • 全表扫描

  • 记录排序

  • 冗余索引

总结

全表扫描 -> 添加索引避免全表扫描 -> 新的SQL语句需要排序 -> 新建索引避免排序 -> 发现冗余索引并修复

6、代维·《百万并发下PHP协程+异步非阻塞框架设计实践》

  • 为什么用协程,什么是协程

    1、连接数
    2、并发
    3、性能

  • web io 模型

    1、php-fpm: 请求 – 进程
    2、java: 请求 – 线程
    3、Golang: 请求 – 协程
    4、nodejs: 请求 – callback

7、卜赫·《从支持一个APP的后端到BaaS平台的探险》

8、范圣佑·《从学徒变大师:谈 Laravel 框架扩充与套件开发》

9、惠新宸·《PHP7高性能之源》

10、徐汉彬·《QQ会员活动平台的PHP7升级实践》

11、胡波·《手机微博升级PHP7那些事儿》