标签归档:PHP内核

PHP文件上传进度的实现原理

在PHP5.4之前,如果我们要获取文件上传的进度,可以选择的方案有Flash或使用PHP的uploadprogress扩展。这两种方案存在本质的区别,Flash的上传进度是客户端上传的进度,它是基于本地OS的网络传输,最终其本质上也是一次HTTP的multipart/form-data编码的POST请求;uploadprogress扩展需要依靠JS获取服务器提供的进度,这里的进度是服务器接收的文件进度。

而在PHP5.4之后,我们可以在不添加扩展的情况下,从session数据中获取了文件上传的进度。uploadprogress扩展和PHP5.4的session扩展都能获取上传的进度,其是否有相同的地方呢?

我们先来看uploadprogress扩展,下载源码包,解圧,直接打开文件,我们可以在example中找到一个简单的示例。在info.php文件中,uploadprogress_get_info函数用来获取上传文件进度。upploadprogress.c文件存储了扩展的实现过程。uploadprogress扩展实现的关键在于其模块寝化函数:

PHP_MINIT_FUNCTION(uploadprogress)
{
	REGISTER_INI_ENTRIES();
	php_rfc1867_callback = uploadprogress_php_rfc1867_file;
 
	return SUCCESS;
}

此函数的核心就是设置php_rfc1867_callback为uploadprogress_php_rfc1867_file。
设置这个函数指针有什么用呢?
在前面的文章PHP内核中文件上传类型的获取过程中我们了解到PHP处理POST请求的函数是SAPI_POST_HANDLER_FUNC(rfc1867_post_handler)(main/rfc1867.c)。在这里, 我们发现了若干个php_rfc1867_callback的调用,从调用的第一个参数来看,它可以分为六个事件,或者说有六个回调更新点。

如果此时我们查看PHP5.4的的session扩展的实现文件session.c时,搜索php_rfc1867_callback,你会发现在模块初始化函数中也有与扩展类似的赋值操作:

	php_rfc1867_callback = php_session_rfc1867_callback;

同样,在php_session_rfc1867_callback函数中有与uploadprogress同样的六个事件的处理,这六个事件相当于六个钩子程序,分别对应POST请求的处理的六个不同的位置,在PHP5.4中他们的作用分别是:

  • 1、MULTIPART_EVENT_START 在处理所有的请求实体之前,初始化上传进度信息,比用于记录上传进度相关信息的progress结构体信息(如content-length)
  • 2、MULTIPART_EVENT_FORMDATA 对于每个multipart包含的控制,执行此步初始化操作,以此之前会解析Content-Disposition相关属性,并初始化progress的其它信息,如session_id,以及整个上传活动的key,这里表示整个上传进度准备好了。
  • 3、MULTIPART_EVENT_FILE_START 开始处理上传的文件信息,如果progress的data不存在,则会创建此结构,并初始化session中存储的对于此次文件上传的start_time、content_length、bytes_processed、files等信息。然后处理单个文件的上传属性,如field_name、tmp_name等。对于tmp_name等字段这里是执行初始化操作。这一步的时候获取session 的值才会开始有上传进度的相关信息。
  • 4、MULTIPART_EVENT_FILE_DATA 更新上传文件的长度,在一堆的文件相关信息检测和临时文件写入之前,也是在将数据写入到$_FILES之前。
  • 5、MULTIPART_EVENT_FILE_END 单个文件上传结束,此时会更新这个文件相关的一些信息,比如error, tmp_name,tmp_name字段在start时是null。当然这里还有针对当前文件的done字段的更新。
  • 6、MULTIPART_EVENT_END 更新session数组的最后的一些结信息 比如done字段 并清空progress的信息,

这里的六个事件是相同的,而uploadprogress扩展和PHP5.4的session扩展在事件处理过程中中间存储结构和最后的返回内容与方式上存在一些差异。uploadprogress扩展的存储结构为一个按照扩展制定的规则生成的临时文件,最后是通过扩展函数uploadprogress_get_info返回上传进度的数组。PHP5.4的存储结构为SESSION的存储方式,或者是文件,或者是memcache,这个按session的设置来,其最终是通过$_SESSION返回相关数组。

除了uploadprogress扩展外,APC也以设置php_rfc1867_callback = apc_rfc1867_progress,提供了类似的解决方案,启动此功能需要在php.ini中设置apc.rfc1867项为启用,并且在表单中加一个隐藏域 APC_UPLOAD_PROGRESS,这个域的值可以随机生成一个hash,以确定此次上传操作的唯一性。通过Ajax调用服务端显示进度的接口,在接口中通过apc_fetch函数获取APC缓存的文件上传进度。比如print_r(apc_fetch(“upload_$_POST[APC_UPLOAD_PROGRESS]“));可以得到如下结果:

Array
(
    [total] => 1142543
    [current] => 1142543
    [rate] => 1828068.8
    [filename] => test
    [name] => file
    [temp_filename] => /tmp/php8F
    [cancel_upload] => 0
    [done] => 1
)

apc.rfc1867相关更加详细的内容猛击 APC Runtime Configuration

PHP变量的CV类型

PHP变量的CV类型

在我们使用VLD扩展查看PHP生成的中间代码时,经常会看到有这样一项:compiled vars: !0 = $a,或者如果使用更加详细的 -dvld.verbosity=3参数,会看到IS_CV,IS_VAR等类型。这里所说的Compiled vars和IS_CV都与今天我们所要了解的CV类型有莫大的关系。

CV者,Compiled variable也。
CV类型是PHP编译过程中产生的一种变量类型,以类似于缓存的方式,提高某些变量的存储速度。
与CV类型同一级别的类型还有:

	#define IS_CONST (1<<0)
	#define IS_TMP_VAR (1<<1)
	#define IS_VAR (1<<2)
	#define IS_UNUSED (1<<3) /* Unused variable */
	#define IS_CV (1<<4) /* Compiled variable */

比如最常见的赋值语句:$a = 10;

以php -dvld.active=1 -dvld.verbosity=3 test.php(这段代码在放在test.php文件中)查看。

 
	function name:  (null)
	number of ops:  3
	compiled vars:  !0 = $a
	line     # *  op            return  operands
	----------------------------------------------
	   2     0  >   EXT_STMT       RES[  IS_UNUSED  ]         OP1[  IS_UNUSED  ] OP2[  IS_UNUSED  ]
		 1      ASSIGN                 OP1[IS_CV !0 ] OP2[ ,  IS_CONST (0) 10 ]
	  13     2    > RETURN                 OP1[IS_CONST (0) 1 ]

如上我们可以知道10的类型为IS_CONST,$a的类型为IS_CV。

这里的CV类型在代码运行时存储在哪呢?在什么时候能起到性能优化的作用?

我们知道PHP中间代码运行的数据大部分都放在全局变量execute_data中,对于这个变量我们通常以EX(element)的方式调用,如EX(CVs)、EX(opline)等等。通过对execute_data所有字段的查阅我们可以大概知道CV类型变量存放在EX(CVs)中。

如何判别呢?
同样,以上面的简单赋值语句为例,依据其中间代码(ZEND_ASSIGN),操作数的类型(IS_CV和IS_CONST),可以得出其中间代码最终执行的函数为:ZEND_ASSIGN_SPEC_CV_CONST_HANDLE。在此函数中,对于操作数据处理:

	zval *value = &opline->op2.u.constant;
	zval **variable_ptr_ptr = _get_zval_ptr_ptr_cv(&opline->op1, EX(Ts), BP_VAR_W TSRMLS_CC);

op2为右值,op1为左值,左值的查找处理是_get_zval_ptr_ptr_cv。如下:

	static zend_always_inline zval **_get_zval_ptr_ptr_cv(const znode *node, const temp_variable *Ts, int type TSRMLS_DC)
	{
		zval ***ptr = &CV_OF(node->u.var);
 
		if (UNEXPECTED(*ptr == NULL)) {
			return _get_zval_cv_lookup(ptr, node->u.var, type TSRMLS_CC);
		}
		return *ptr;
	}
 
	// 函数中的CV_OF宏定义
	#define CV_OF(i)     (EG(current_execute_data)->CVs[i])

上面的函数和宏定义道出了CV这个类缓存机制的实现过程和CV类型的存储位置。

在函数中,程序会先判断变量是否存在于EX(CVs) – 这就是存储位置,如果存在则直接返回,否则调用_get_zval_cv_lookup,通过HashTable操作在EG(active_symbol_table)表中查找变量。虽然HashTable的查找操作已经比较快了,但是与原始的数组操作相比还是不在一个数量级。这就是CV类型变量的性能优化点所在。

以上是变量的赋值操作,也是变量的创建过程,与此对应,在变量销毁时PHP内核应该会对此种类型的变量执行清除HashTable和数组两个操作,以unset操作为例,针对IS_CV类型的变量,其中间代码最终会执行ZEND_UNSET_VAR_SPEC_CV_HANDLER。在此函数中不管是ZEND_QUICK_SET类型的操作,还是常规的unset操作,都会对HashTable(EG(active_symbol_table)或target_symbol_table)和数组(EX(CVs)和ex->CVs)执行清除操作。

PHP中的字符串连接操作

上周和刘志强同学讨论字符串的连接操作:
一般情况下我们用点号做字符串的连接操作,但是如果在某个长字符串中放一个变量,通常我们会采用在字符串中直接写入一个变量的方式来实现

$var = 10;
$str = "test string begin " . $var . " end";
 
//或
$var = 10;
$str = "test string begin $var end";

这二者有什么区别呢?

以VLD扩展直接查看这两段代码生成的中间代码:
点号连接:

number of ops:  7
compiled vars:  !0 = $var, !1 = $str
line     # *  op         ext  return  operands
------------------------------------------------
   2     0  >   EXT_STMT
         1      ASSIGN                  !0, 10
   3     2      EXT_STMT
         3      CONCAT          ~1      'test+string+begin+', !0
         4      CONCAT          ~2      ~1, '+end'
         5      ASSIGN                  !1, ~2
         6    > RETURN                  1

直接在字符串中插入变量:

number of ops:  8
compiled vars:  !0 = $var, !1 = $str
line     # *  op             ext  return  operands
----------------------------------------------------
   2     0  >   EXT_STMT
         1      ASSIGN                      !0, 10
   3     2      EXT_STMT
         3      ADD_STRING          ~1      'test+string+begin+'
         4      ADD_VAR             ~1      ~1, !0
         5      ADD_STRING          ~1      ~1, '+end'
         6      ASSIGN                      !1, ~1
         7    > RETURN                      1

对比这段生成的中间码,其原理完全不一样:

点号是典型的连接操作(当然,它本来就是连接操作),
当使用多个点号是,每两个点号的结果都会使用一个临时变量存储起来,并作为下一个操作的一个操作数。如在我们的示例中,首先是执行第一个连接操作,将“test string begin ”和$var连接起来,得到“test string begin 10”,然后再执行第二个连接操作,将上一个操作得到的结果“test string begin 10”和” end”连接起来,并将结果存储在另一个临时变量,最后将第二个连接操作的结果赋值给$str。

连接操作对应的opcode为ZEND_CONCAT,对于所给的两个操作数,其最终通过concat_function函数将两个字符串连接起来,如果所给的变量的类型不是字符串,则会通过zend_make_printable_zval将其转换成字符串。concat_function函数会根据两个字符串的长度重新分配内存,并执行两次拷贝操作,将两个字符串拷贝到新的内存空间。
这里针对两个字符串相同的情况有一个特殊处理。
如下:

if (result==op1) {	/* special case, perform operations on result */
	uint res_len = Z_STRLEN_P(op1) + Z_STRLEN_P(op2);
 
	Z_STRVAL_P(result) = erealloc(Z_STRVAL_P(result), res_len+1);
 
	memcpy(Z_STRVAL_P(result)+Z_STRLEN_P(result), Z_STRVAL_P(op2), Z_STRLEN_P(op2));
	Z_STRVAL_P(result)[res_len]=0;
	Z_STRLEN_P(result) = res_len;
} else {
	Z_STRLEN_P(result) = Z_STRLEN_P(op1) + Z_STRLEN_P(op2);
	Z_STRVAL_P(result) = (char *) emalloc(Z_STRLEN_P(result) + 1);
	memcpy(Z_STRVAL_P(result), Z_STRVAL_P(op1), Z_STRLEN_P(op1));
	memcpy(Z_STRVAL_P(result)+Z_STRLEN_P(op1), Z_STRVAL_P(op2), Z_STRLEN_P(op2));
	Z_STRVAL_P(result)[Z_STRLEN_P(result)] = 0;
	Z_TYPE_P(result) = IS_STRING;
}

示例执行了两次连接操作,则执行了两次内存分配操作和四次拷贝操作。

而直接在字符串中插入变量,其所有的操作都是添加操作,将字符串添加到返回值,将变量添加到返回值,
所有的结果返回都是在一个临时变量中,如我们的示例,首先会将”test string begin “添加到临时变量,然后将临时变量和$var变量添加到临时变量,之后将临时变量和” end”添加到临时变量,最后将此此时变量赋值给$str。这里添加将字符串添加到临时变量,其对应的opcode为ZEND_ADD_STRING,将变量添加到临时变量,其对应的opcode为ZEND_ADD_VAR,虽然这两个操作的opcode不同,但其最终调用都是add_string_to_string,他们所不同的调用此函数的第三个参数,一个是操作码存储的ZVAL变量,一个是通过变更列表获取的ZVAL变量。
其调用结构如下:

// 添加字符串
zval *str = &EX_T(opline->result.u.var).tmp_var;
add_string_to_string(str, str, &opline->op2.u.constant);
 
//添加变量
zval *str = &EX_T(opline->result.u.var).tmp_var;
zval *var = _get_zval_ptr_tmp(&opline->op2, EX(Ts), &free_op2 TSRMLS_CC);
add_string_to_string(str, str, var);

在添加变量时,如果添加的变量不是字符串,会通过zend_make_printable_zval将变量转换成字符串输出,如数组会转换成Array。
add_string_to_string的实现在Zend/zend_operators.c文件中:

/* must support result==op1 */
ZEND_API int add_string_to_string(zval *result, const zval *op1, const zval *op2) /* {{{ */
{
	int length = Z_STRLEN_P(op1) + Z_STRLEN_P(op2);
 
	Z_STRVAL_P(result) = (char *) erealloc(Z_STRVAL_P(op1), length+1);
	memcpy(Z_STRVAL_P(result)+Z_STRLEN_P(op1), Z_STRVAL_P(op2), Z_STRLEN_P(op2));
	Z_STRVAL_P(result)[length] = 0;
	Z_STRLEN_P(result) = length;
	Z_TYPE_P(result) = IS_STRING;
	return SUCCESS;
}
/* }}} */

add_string_to_string函数的实现过程是针对即将生成的字符串的大小重新通过PHP内核的内存管理扩展内存空间(如果当前空间后续的内存够用,则天下太平,如果空间不够,则重新分配空间并执行拷贝操作),并将新的字符串复制到原始字串后面内存空间的过程。
我们的示例执行了三次添加操作,也就执行了三次内存扩展操作和三次拷贝操作。