作者归档:admin

PHP执行过程中的数据

PHP脚本在内核中一般会经过词法解析,语法解析、编译生成中间代码,执行中间代码这样四个大的步骤。其中,第四个步骤,执行中间代码PHP内核默认情况下是通过zend/zend_vm_execute.h文件中的execute函数调用执行完成,对于所有的中间代码,默认实现是以按顺序执行,当遇到函数等情况时跳出去执行,执行完后再回到跳出的位置继续执行。

与过程相比,过程中的数据会更加重要,那么在执行过程中的核心数据结构有哪些呢? 在Zend/zend_vm_execute.h文件中的execute函数实现中,zend_execute_data类型的execute_data变量贯穿整个中间代码的执行过程, 其在调用时并没有直接使用execute_data,而是使用EX宏代替,其定义在Zend/zend_compile.h文件中,如下:

#define EX(element) execute_data.element

因此我们在execute函数或在opcode的实现函数中会看到EX(fbc),EX(object)等宏调用, 它们是调用函数局部变量execute_data的元素:execute_data.fbc和execute_data.object。 execute_data不仅仅只有fbc、object等元素,它包含了执行过程中的中间代码,上一次执行的函数,函数执行的当前作用域,类等信息。 其结构如下:

typedef struct _zend_execute_data zend_execute_data;
 
struct _zend_execute_data {
    struct _zend_op *opline;
    zend_function_state function_state;
    zend_function *fbc; /* Function Being Called */
    zend_class_entry *called_scope; 
    zend_op_array *op_array;  /* 当前执行的中间代码 */
    zval *object;
    union _temp_variable *Ts;
    zval ***CVs;
    HashTable *symbol_table; /* 符号表 */
    struct _zend_execute_data *prev_execute_data;   /* 前一条中间代码执行的环境*/
    zval *old_error_reporting;
    zend_bool nested;
    zval **original_return_value; /* */
    zend_class_entry *current_scope;
    zend_class_entry *current_called_scope;
    zval *current_this;
    zval *current_object;
    struct _zend_op *call_opline;
};

在前面的中间代码执行过程中有介绍:中间代码的执行最终是通过EX(opline)->handler(execute_data TSRMLS_CC)来调用最终的中间代码程序。 在这里会将主管中间代码执行的execute函数中初始化好的execture_data传递给执行程序。

zend_execute_data结构体部分字段说明如下:

  • opline字段:struct _zend_op类型,当前执行的中间代码
  • op_array字段: zend_op_array类型,当前执行的中间代码队列
  • fbc字段:zend_function类型,已调用的函数
    called_scope字段:zend_class_entry类型,当前调用对象作用域,常用操作是EX(called_scope) = Z_OBJCE_P(EX(object)), 即将刚刚调用的对象赋值给它。
  • symbol_table字段: 符号表,存放局部变量,这在前面的<< 第六节 变量的生命周期 » 变量的作用域 >>有过说明。 在execute_data初始时,EX(symbol_table) = EG(active_symbol_table);
  • prev_execute_data字段:前一条中间代码执行的中间数据,用于函数调用等操作的运行环境恢复。
    在execute函数中初始化时,会调用zend_vm_stack_alloc函数分配内存。 这是一个栈的分配操作,对于一段PHP代码的上下文环境,它存在于这样一个分配的空间作放置中间数据用,并作为栈顶元素。 当有其它上下文环境的切换(如函数调用),此时会有一个新的元素生成,上一个上下文环境会被新的元素压下去, 新的上下文环境所在的元素作为栈顶元素存在。

在zend_vm_stack_alloc函数中我们可以看到一些PHP内核中的优化。 比如在分配时,这里会存在一个最小分配单元,在zend_vm_stack_extend函数中, 分配的最小单位是ZEND_VM_STACK_PAGE_SIZE((64 * 1024) – 64),这样可以在一定范围内控制内存碎片的大小。 又比如判断栈元素是否为空,在PHP5.3.1之前版本(如5.3.0)是通过第四个元素elelments与top的位置比较来实现, 而从PHP5.3.1版本开始,struct _zend_vm_stack结构就没有第四个元素,直接通过在当前地址上增加整个结构体的长度与top的地址比较实现。 两个版本结构代码及比较代码如下:

// PHP5.3.0
struct _zend_vm_stack {
    void **top;
    void **end;
    zend_vm_stack prev;
    void *elements[1];
};
 
if (UNEXPECTED(EG(argument_stack)->top == EG(argument_stack)->elements)) {
}
 
//  PHP5.3.1
struct _zend_vm_stack {
    void **top;
    void **end;
    zend_vm_stack prev;
};
 
if (UNEXPECTED(EG(argument_stack)->top == ZEND_VM_STACK_ELEMETS(EG(argument_stack)))) {
}
 
#define ZEND_VM_STACK_ELEMETS(stack) \
((void**)(((char*)(stack)) + ZEND_MM_ALIGNED_SIZE(sizeof(struct _zend_vm_stack))))

当一个上下文环境结束其生命周期后,如果回收这段内存呢? 还是以函数为例,我们在前面的函数章节中<< 函数的返回 >>中我们知道每个函数都会有一个函数返回, 即使没有在函数的实现中定义,也会默认返回一个NULL。以ZEND_RETURN_SPEC_CONST_HANDLER实现为例, 在函数的返回最后都会调用一个函数zend_leave_helper_SPEC。

在zend_leave_helper_SPEC函数中,对于执行过程中的函数处理有几个关键点:

  • 上下文环境的切换:这里的关键代码是:EG(current_execute_data) = EX(prev_execute_data);。 EX(prev_execute_data)用于保留当前函数调用前的上下文环境,从而达到恢复和切换的目的。
  • 当前上下文环境所占用内存空间的释放:这里的关键代码是:zend_vm_stack_free(execute_data TSRMLS_CC);。 zend_vm_stack_free函数的实现存在于Zend/zend_execute.h文件,它的作用就是释放栈元素所占用的内存。
  • 返回到之前的中间代码执行路径中:这里的关键代码是:ZEND_VM_LEAVE();。 我们从zend_vm_execute.h文件的开始部分就知道ZEND_VM_LEAVE宏的效果是返回3。 在执行中间代码的while循环当中,当ret=3时,这个执行过程就会恢复之前上下文环境,继续执行。

更多内容请请移步TIPI项目

胖子的乱看乱想笔记二

1、最困难的时候,你需要做的就是坚持突围,不要想别的,因为没有其他的路可以走。-- 乐淘网CEO毕胜

2、一个好的Leader做好两个字就够了:“勇”和“容”。前者是勇于承担责任;后者是从内心包容下属。 -- 网络:双鱼座

3 、过程的形参名必须局部于有关的过程体–SICP

4、你得让计算机告诉你它在干什么,它干了什么!

5、项目越大,所需要的人越多,从而沟通的成本也就会越高,如果解决了沟通问题呢?

6、并发,时间是一个本质问题 ﹣SCIP

7、将语法分析和执行分离,分离后,可以专注优化各部分,各自成长。

8、第一,要相信没有什么真正难的程序;第二,要意识到程序是写给人看的。–Bernie Cosell

9、不要只阅读那些编程习惯跟自己一样的家伙的代码–Dinald Knuth

10、都是解渴,有的白开水,有的要泡杯茶 - Damon Peng

11、遇到问题,一定要到现场亲自观察确认问题的根本原因,不要用经验轻易下结论。现场有神灵。

12、有其他涉众的问题,先沟通,再做事。

13、做技术也需要了解你的产品所处的环境,可能出问题的不是你的代码,而是你的代码所在服务器国家的某些政策和法规。

14、预警机制的方式不能仅仅是邮件,在这里也应该有高可用性的考量,确保一种方式失效后有其它的方式可以马上替换或自动切换。

15、1.写文章,多发表个人见解,增加个人思考机会;2.大量看书,自学,但一定要选好书;3.多和圈里高手交流,听君一席话,胜读十年书;4.建立个人文件管理系统,不断整理自己的原创;5.参加系统学习,找到短板,快速学习;6.实践,大量实践! — 李开复: 如何提升个人专业能力

16、经验这东西,往往并不能告诉我们什么一定对,但是可以告诉我们什么一定不对。﹣霍炬

17、书是一个很好弥补没有高手在场的方法,因为书是最好的老师。﹣徐宥

18、分析每天时间怎么花的

19、系统发布时要考虑预热时间。

19、 自古不谋万世者,不足谋一时; 不谋全局者,不足谋一域。 —[清] 陈澹然《寤言二迁都建藩议》

20、不登上山顶,你就无法体会登顶的感觉,也无法看到山顶的风景。

21、成功的几率很小,因为必须同时应对的因素太多 - 《形式综合论》

22、敬人者人恒敬之 爱人者人恒爱之 - 《孟子》

23、 我的天性是挺胸直立,骄傲而无所畏惧,勇敢地面对这个世界。-《管理精英宣言》

24、制定计划从大到小,实施计划从小到大,先有想法,然后再想办法让想法落地。

以上的内容纯粹属于胖子各种时间记录在evernote的汇集,此版权不属于胖子

一次查询优化过程

问题描述

在正在维护的系统中有一个数据分析的模块,用于来分析一些用户访问的数据。其中有一个操作是查找某URL地址对应的ID。在这里ID与URL是存储MySQL数据的一个表中,此表就两个字段,id,url.表存储引擎类型MyISAM,当然URL字段是加了索引的。现在每天按小时定时分析数据,开始程序没有问题,当几年的数据积累下来,特别是最近业务量增加时,明显感觉到程序的执行过程变得很漫长,通过xdebug分析一次执行过程的所有执行时间,发现瓶颈在于前面所提到的通过URL地址对应的ID。下面就开始了漫长的优化之路。

第一次优化:优化细节,针对特殊地址的优化

由于应急,先考虑一些细节的调整:
首先,我们针对一些特殊的地址进行了处理,直接返回ID,比如没有URL的情况,比如Google的首页地址;
然后,我们针对一些常见的地址作为Hash存储,以及一些热数据进行内存缓存。

结果,提高一些性能,能满足当时的业务需求,特别是当特殊的地址较多的时候,其情况还是非常乐观的。

过了一段时间,到了另一个高峰点,发现此分析模块仍然会时不时的出些问题,导致数据不准确,各种情况,各种应付…不得已,开始思考另一个方案。

第一个方案: key-value数据库

依据前面的对于热点数据,将其存储到内存缓存的思路,我们考虑是否将所有数据都作为热点数据,于是先做前期预研,将部分数据导到redis中,发现速度有了极大的提升,大概在500倍的一个量级,那叫一个激动,于是决定将所有数据都迁移到redis中,想法是美好的,结果是不言而喻的。失败了。为什么呢?很简单,没资源,我们没有那么大的内存存储N个上千万的表。

第二个方案:基于单词查找树的文件结构

从前面的key-value数据库方案看,存储url到id的映射,在实现思路上还是可行的,于是开动了小心思,既然内存不够用,那么用硬盘呢?

这个既便宜又实惠,是居家旅行,杀人越货的必备良品。于是计划以URL的主域名为目录,以每个地址的md5值为文件名,每个文件存储这个地址对应的ID。考虑到域名可能很多,于是计划使用变形的单词查找树来设置多级目录,但是当域名地址太长时,文件系统在生成目录的时候会出错,只得去掉单词查找树,使用某种简单的按主域名转化后的字符串转建立目录。在预研时,先生成了5万数据的文件结构,发现生成的速率很慢,并且由于大量小文件的生成,对于整个目录的查询会很慢,但对于单个文件的读取还是很快的,然而将随着数据生成越来越多,当达到40万时,整个目录占用了大概4G+的硬盘空间。

假想一下,当1千万的数据以这种方式存储到硬盘上,会是多少?如果数据持续增加呢?到达一个亿呢?感觉到不靠谱了。于是继续想下一种方案,这个方案继续执行。

第三个方案:信赖于数据库,增加md5值存储的字段

在第二种方案中,我们是使用md5值作为文件名,在想在数据库对于md5后的文件名的查找会更快一些呢?在ID和URL映射表中,增加一个字段url_md5,存储url使用md5后的值,在这里我们直接使用MySQL的md5函数更新表数据,测试后,发现其速度有了显著提升,单个查找操作大概能提升50倍+。整体性能提升5倍的样子。于是,果断采用此方案,结果是该分析模块一直没啥事发生。(^_^)

总结

  1. 不要过早优化
  2. 优化要先找瓶颈
  3. 数据结构和对工具的使用很重要
  4. 优化时需要理清问题的根本原因是什么,最好能到理论层面或实现原理层面。