PHP-PM 执行原理

大体流程如下:主进程监听两个socket,一个接收外部 http 请求(web 服务器),另一个与子进程通信。主进程通过 proc_open 调用创建子进程,每个子进程会监听一个 socket(http 服务器),主进程将 http 请求转发给子进程进行处理。子进程在 bootstrap 阶段会 new 一个 Application (假设是 symfony 框架),后面所有的请求都不会再重复初始化 Application (因此比传统 PHP-FPM 执行速度快)。

画了一个图

PHP7 的高性能来自于哪些改进

  • 变量容器 zval 结构体定义改变,减少内存占用,减少引用计数相关操作。
  • zend_string。字符串复制的时候,采用引用赋值,zend_string可以避免的内存拷贝。
  • zend_array。数组的value默认为zval。
    HashTable的大小从72下降到56字节,减少22%。
    Buckets的大小从72下降到32字节,减少50%。
    数组元素的Buckets的内存空间是一同分配的。
    数组元素的key(Bucket.key)指向zend_string。
    数组元素的value被嵌入到Bucket中。
    降低CPU Cache Miss。
  • 改进函数调用机制。
  • 通过宏定义和内联函数(inline),让编译器提前完成部分工作

参考链接:

  1. http://www.csdn.net/article/2015-09-16/2825720
  2. PHP’s new hashtable implementation
  3. Internal value representation in PHP 7 – Part 2

PHP内存回收原理

每个php变量存在一个叫”zval”的变量容器中。除了包含变量的类型和值,还包括两个字节的额外信息。is_ref 是个bool值,用来标识这个变量是否是属于引用集合(reference set),refcount 用以表示指向这个zval变量容器的变量(也称符号即symbol)个数

refcount 为0时变量从内存中删除。在5.3之前的版本无法处理循环引用的问题。5.3及以后, 在引入新的垃圾回收算法来对付循环引用计数的时候, 作者加入了大量的宏来操作refcount, 为了能让错误更快的显现, 所以改名为refcount__gc, 迫使大家都使用宏来操作refcount。

一个zval在5.3之前版本占用24字节(64位系统,下同),5.3为了解决循环引用的问题,用zval_gc_info劫持了zval的分配,因此5.3到5.6,一个zval实际占用32字节。

从PHP7开始, 对于在zval的value字段中能保存下的值, 就不再对他们进行引用计数了, 而是在拷贝的时候直接赋值, 这样就省掉了大量的引用计数相关的操作, 这部分类型有:IS_LONG、IS_DOUBLE,对于那种根本没有值, 只有类型的类型, 也不需要引用计数了:IS_NULL、IS_FALSE、IS_TRUE。

PHP7的性能,我们并没有引入什么新的技术模式, 不过就是主要来自, 持续不懈的降低内存占用, 提高缓存友好性, 降低执行的指令数的这些原则而来的。

PHP5(v<5.3) zval 结构体定义:

PHP5(5.3<= v < 7) zval 结构体定义:

5.3及以上版本虽然 struct  _zval_struct 结构体的内容没有变(除了 refcount 重命名为 refcount__gc,is_ref 重命名为 is_ref__gc),但是新增的头文件 zend_gc.h 重定义了 ALLOC_ZVAL 宏

zval_gc_info 的定义为

所以实际上5.3及以上版本zval大小为32字节。

PHP7 zval 结构体定义如下

 

关于内存对齐请参考:https://levphy.github.io/2017/03/23/memory-alignment.html

Opcache 开启前后性能对比

测试环境介绍

机器是一台基于 vmware 的虚拟机

程序是 yii2-app-basic , HelloController.php 文件内容如下:

测试命令: ab -n10000 -c100 ‘http://yii2.app.com:8090/index.php?r=/hello/world’

测试结果:

 Opcache CPU占用 Requests per second(吞吐率)
未开启 99% 520
开启 99% 5480

用 strace 追踪 php-fpm 的系统调用(strace 会严重影响性能,追踪系统调用时用的测试命令是:ab -n1000 -c100 ‘http://yii2.app.com:8090/index.php?r=/hello/world’,总请求减少为之前的10%),结果如下:

测试结果分析:

Opcache 开启前后 cpu 使用率都达到了 100% 说明系统瓶颈在 cpu。开启 Opcache 后系统调用少了很多,特别是 fstat,mumap,open,mmap,开启后,这几个系统调用可以忽略不计。Opcache 省去了每次加载和解析 PHP 脚本的开销,一次加载解析后后续请求不用去读源码,因此少了这么多系统调用。

结论:提高PHP程序的性能,最重要也最有效的方法就是开启 Opcache。

其它:  最初 fpm 配置是监听端口,吞吐率在开启Opcache前只有340左右;开启Opcache后在900左右,cpu占有80%,无法达到100%;如果请求过多,则会出现超时错误。后来改 fpm 监听 unix sock,性能一下子上来了。Yii2 开启  debug 模式后,吞吐率为 1200  左右。

Is this php’s bug?

I am reading yii2’s source code right now. I found that this method yii\di\Instance::ensure something werid。

I changed the code as following:

I got output as :

string(15) “yii\di\Instance”

Can anyone explain?

#Answer

Just now(2016-04-12 15:20:58),I asked Laruence about this questing in qq group.  He answered me that get_calss(null) will return current scope. Then I read the php documetation , It says:

If object is omitted when inside a class, the name of that class is returned.

So, RTFM si right.

compile php with openssl on mac osx error

从源码手动编译 PHP 时出现如下错误:

解决办法

MakeFile 里面找到类似下面这一行:

删除所有的 -lssl 和 -lcrypto 然后添加 libssl.dylib 和 libcrypto.dylib 的路径(如果你安装了 brew,那么则是 /usr/local/opt/openssl/lib/),重新运行 make 命令,done。

附上我修改后的 MakeFile EXTRA_LIBS 那一行:

 

PHP 数值型字符串比较的坑

上面代码在 PHP5.5 返回 false,在 PHP5.3 返回 true。

分享一个 MySQL 分库分表类

当一个表数据记录过大时就会出现性能瓶颈,而一般对应的解决办法是要么做分区表,要么分表,分区表就不说了,分表又分为垂直分割和水平分割,具体区别请自行搜索。一般而言,分库分表属于水平分割,按照一定的规则将数据插入到不同的表中去。而分库则可以很方便的转移数据库的压力,比如将一个很大库的分别放在不同的服务器上。

下面是我写的一个分库分表的实现:

Config 类就做一个事情,根据配置文件,去拿到对应的库和表的链接配置,然后客户可以根据 dsn 去链接对应的数据库。对应的配置文件如下:

给出一个使用这个分库分表的例子:

下面这个例子展示了如何使用上述的 Model 类:

如果看官您有任何疑问或者有更好的实现,欢迎交流~

PHP 取一个整数的十位上的数值可能出现的 bug

问:如何取到一个整数的十位上的数值?

答:先除以 10 再对 10 取余。代码如下:

很简单是不是?但这段代码有 bug。你可以运行下面这段代码:

输出如下:

buggggggggggeeeeee

可以看到整数 9223372036854775807 的十位数上是 0 ,而我们确得到了 2 ,这是怎么一回事呢?

我们执行下如下代码:

输出为:

RTX截图未命名

可以看到, 9223372036854775807 不能被 10 整除,$a / 10 后得到的是一个浮点数,丢失了精度,这个时候再对 10 取模得到的值就不准了。

请时刻记住 PHP 变量的类型

我们都知道 PHP 变量类型是弱类型,这样很方便,当你需要一个数字时,变量就表现得像个 Int,当你需要字符串时,变量就表现得像个 String。但方便的同时,如果不注意也会带来坑,并且这种情况带来的 bug 还很不好排查。今天我就遇到了一个。

游戏新注册用户的时候需要生成一个 uid,一般来说,在数据量小且低并发的时候直接使用 MySQL 的自增 ID 就可以生成得到唯一的 uid,但如果数据量大且并发很高,使用 MySQL 的自增 ID 就不能满足需求了。我们使用了一个叫 ukg 的东西,该服务的功能就一个,每次调用它,就给你返回一个唯一的数字,嗯,很好,刚好能满足我们生成 uid 的需求。

代码写完后,测试的过程中发现了一个 bug,设备第一次登录的时候会登录失败,第二次及以后就登录成功。排查了近 1 个小时才找到问题所在,设备第一次登录的时候,我们访问 ukg 得到一个数字,当做玩家的 uid,并且存入 MySQL,后来发现我们从 ukg 返回得到的实际上是一个 数字+空格+回车 组成的一个字符串,而空格和回车都是不可见字符串,很容易就忽略了,存入 MySQL 时,MySQL 进行了转换将空格和回车去掉然后正确存进了数据库。这样就能解释为什么第一次登录失败,第二次及以后的请求就没问题了。

定位 bug 后,解决就很容易了,从 ukg 取到数据后,将其强制转换为 Int 就 OK 了。

虽然,PHP 的语法并不要求一个变量强制其数据类型,但我们在写代码的过程中,还是需要时刻注意变量的数据类型。常见的错误还有 0 == false 相等导致的逻辑出错。如果不嫌麻烦的话,所有 == 的地方都改成 === 就不会出现这类型的 bug 了。