某商vps上编译php时报错“undefined reference to `libiconv_open'”的处理

帮朋友的阿里云的服务器装wordpress。该服务器上面已经装了有好几个站点,web环境是wdlinux的所谓一键安装脚本,向来极其厌恶这种所谓的一键脚本,版本老化,目录不合理,乱。但为了兼容现有环境,还是决定在它上面继续。无语的是,这个web配置实在乱透了,nginx作前端,把动态请求反代到后方apache上,这样配置一个web站点,要同时设置两套web。而且还是使用php 5.2.17,这个老掉牙的版本!搞了半天,真心不想搞下去了。于是决定新安装php新版本,以php-fpm运行,简洁优雅地在nginx上跑。

之前自己服务器上路的是php 7.0.9,直接下载这个版本源码,使用之前自己的configure参数,但在make时出错了,错误消息第一行非常长,核心就是iconv有问题

undefined reference to `libiconv_open'

尝试安装iconv-devel等办法都使用了,都不行。

经过google,也有别的朋友遇到同样问题,make时加参数即可,如下:

 make ZEND_EXTRA_LIBS='-liconv'

堪称完美,在所有解决方案里最简便,向该博客作者表示感谢。 继续阅读

php下数据库持久连接,及apache模块下“数据库并发连接数超限”的潜在风险

php下的多个数据库引擎都提供持久连接的特性,实现了“连接池”的作用,让数据库连接“复用”,目的是减少php引擎连接数据库的消耗。这有类似fastCGI协议的设计初衷:让后端进程复用,节省启动关闭CGI进程的性能开锁。

数据库持久连接的实现方式

这需要从php的运行模式说起。典型的php运行模式是传统CGI、fastCGI、web模块三种。

其中CGI模式不支持持久连接,因为php每次处理请求,都是由一个独立的进程(操作系统的进程)处理,请求处理完毕,进程就销毁了,相应的数据连接之类的资源当然也已不存在,所以CGI本身是不支持持久连接的。

fastCGI模式下,php进程由进程管理器所管理。(apache下实现实例,参看这里)。不管哪种fastCGI方案,其背后都是一系列长期运行的进程(操作系统下的进程),进程本身可以保持资源,因此,php脚本引擎可以提供应用的接口,允许程序员将数据库连接保持下来,供下次php处理请求,可以直接复用这个连接。

web模块下,类似fastCGI模式。linux下apache默认prefork下,每个httpd进程在同一时刻只响应一个http请求,每个httpd进程可以看做一个fastCGI进程。

多数据库账号的持久连接

假设一web服务器下的所有应用,都是持久连接,并且使用了惟一的数据库连接账号。假设共开了10个fastCGI进程在运行,每个进程都保持了一个持久连接,如果当前处理请求需要连接数据库,直接使用该持久连接即可,不需要新连接数据库。事实上,运行一段时间后,就是这样状态。

假设该web服务器下的应用,共有10个数据库连接账号。每fastCGI进程,从启动开始,每处理一个新的数据库账号相关的请求,就要多保持一个持久连接。因为不同数据库账号的连接,肯定不能复用的。这样,在运行一段时间后,每个fastCGI进程都要维持10个持久连接,分别对应每个数据库账号。

以apache模块模式下运行的httpd进程,可以等同于一个fastCGI进程,上面讨论同样适用。

进程数及连接数讨论,及apache下的潜在风险!

如果web服务器下的的php应用,分别使用了多个数据库账号,而且全部连到同一台数据库服务器。这样,

该数据库的并发连接数 = fastCGI进程数 * 数据库账号数
如果php在apache模块下运行,使用httpd进程数代替fastCGI进程数

通常,fastCGI进程数量是比较有限的,对于一台web服务器,它接受的请求里,大多数请求都是静态的(想像一下,一个页面里,通常只有主html文档是动态,而里面的js,css,图片等等元素都是静态;这里不考虑“静态内容全部移到CDN上”的极端情况)。fastCGI进程数数,通常会远比http并发数小。

在apache模块运行的php下,所有请求都是由httpd进程处理的,每个httpd进程都有可能维护每个数据库用户相关的持久连接,如果数据库用户量较大,这个对mysql服务器并发的连接数影响非常大。通常mysql服务器都会设置一个最大并发数据,超过限制后,就不再受新连接!

php下持久连接的更多信息,参考官方文档 http://php.net/manual/zh/features.persistent-connections.php

 

CGI原理示例,及CGI,FastCGI,php-cgi,php-fpm等的总结

CGI

CGI全名“通用网关接口”(Common Gateway Interface),是一个技术规范,用来动态生成网页html。理论上可以使用任意语言写,只要支持标准输入输出及环境变量即可(标准输入输出概念参考C语言中stdio库的printf函数)。

举例简述一下实现细节,以类C语言伪代码演示(不想了解CGI细节可以跳过)

CGI程序 /usr/local/cgi/hello

printf("Content-type: text/html; charset=UTF-8")
printf("\r\n\r\n")
printf("hello world")

注意两个连续换行符号,它们是http头与内容的分隔。

假设web服务器,把对 http://localhost/hello的请求,转给 /usr/local/cgi/hello 处理,这就要启用一个进程支行hello程序,hello程序执行后标准输出结果如下

Content-type: text/html; charset=UTF-8

hello world

web服务器拿到结果,把并把hello程序的输出结果添加其它http头元素,如HTTP状态码、Connection: keep-alive等,这就是完整的http响应消息内容了,把它们一并发回给浏览器,一次CGI的http请求就完成。

这是个最简单的示例,我们忽略了http请求数据、本地目录文件等,事实上的程序会复杂得多。

通常是这样的,一个cgi-bin目录里,放置CGI可执行程序(类比上面的hello程序),web服务器通常不是把所有请求都通过CGI来处理的,而是把符合一定规则(比如url路径以.pl结尾)的请求,启动CGI进程,并将对应的web目录文件(比如hello.pl)传给CGI程序,CGI程序按hello.pl文件的内容执行,标准输出结果再由web服务器拿到并补充http头等,生成http影响数据,发回给浏览器。

这里的CGI程序的行为,与脚本语言解释器类似(本地目录的相关文件当脚本程序,被CGI程序解释执行)

CGI的具体细节参考rfc3875,或 英文维基CGI词条

FastCGI

传统的CGI程序,对每次http请求,都要启动一个操作系统层面的进程process,进程处理一次就结束。下次http请求还得再起动。启动进程对于操作系统来说是较耗费时间的操作,所以在CGI的负载能力比较有限,在启动关闭进程上浪费严重性能。

针对这一点,FastCGI协议被出了:让CGI进程长期驻守,有请求,就直接给它处理,没有就等待。

可以这样认为,FastCGI是CGI的改进版,虽然并不完全兼容。传统的CGI要改造成FastCGI,很多代码可以直接借用的。

因为CGI/FastCGI协议都是语言无关的,只要能按这个规范来,任何语言都可以。所以有很多具体的技术支持,比如php的CGI/FastCGI模式运行;这点后面讨论。

单个FastCGI进程的负载是有限的,所以通常需要多个进程同时工作,这就可以同时接受更多请求,提高并发数。

如果某个进程运行时间长了,占用了过多内存,或者该进程僵死了,需要结束它,并启动新进程;或者想在并发量大时,自动增加FastCGI进程数,而并发小时,自动减少;...这些就需要有有“人”来管理,就是FastCGI进程管理员的工作了。

php-cgi

编译后php的二进制文件里,在bin目录里有php-cgi文件(在windows版里是,php-cgi.exe),即是支持CGI/FastCGI的可执行程序。

可以这样执行一个php文件  /path/to/php-cgi /path/to/your-php-file.php

php-fpm

前面说过,FastCGI程序是驻守系统进程中的,该进程不可能凭空启动,那这个进程由谁管理呢?这就是FastCGI进程管理员 (FastCGI Process Manager)。对于PHP而言,在php 5.3以后的版本,自带的php-fpm即是php的fpm。(php 5.2及以前版本,可以通过补丁的形式将php-fpm整合到php中,或使用其它方案)。

不过,支持php的fpm并非只有php-fpm,还有其它方案,只要起到管理fastCGI进程的启动、关闭等 功能即可。apache下的mod_fcgid即是另一个可选方案。所以,在apache下,如果使用mod_fcgid整合php,就不需要php-fpm了。有更广泛支持的Spawn-FCGI是另一个备选项。

 

 

php版本(5.3,5.5,7.0)及运行模式(fast-cgi/fpm,apache模块)之间性能对比测试

php 7.0发布在即,一直以来有传言说php7性能有飞跃,于是做了一个测试。

测试环境

硬件  虚拟机2G内存
OS  CentOS 6.7 (kernel 2.6.32-573.7.1.el6.x86_64)
Web  Apache/2.2.15 (centos 6自带)

php版本选择

5.3.3, CentOS 6自带的版本
5.3.29, 官方5.3分支的最后一个版本,用于跟apache模块做对比
5.6.15,
7.0.0beta3

除了第一个CentOS自带5.3.3是apache模块之外,全部跑在fast-cgi (php-fpm) 模式下,通过apache模块mod_proxy_fcgi整合在apache中(整合方式)。每个版本配置一个虚拟站点,域名分别为 a.dom, b.com... 。

php编译参数

三个自编译版本的编译参数如下(在 /usr/loca 目录下,分别安装到子目录里)

'./configure' '--enable-fpm' '--prefix=/usr/local/php53' '--with-config-file-path=/usr/local/php53/etc' '--with-config-file-scan-dir=/usr/local/php53/etc/php.d' '--enable-exif' '--with-gd' '--with-mysql' '--with-mysqli' '--with-pdo-mysql'

'./configure' '--enable-fpm' '--prefix=/usr/local/php56' '--with-config-file-path=/usr/local/php56/etc' '--with-config-file-scan-dir=/usr/local/php56/etc/php.d' '--enable-exif' '--with-gd' '--with-mysql' '--with-mysqli' '--with-pdo-mysql'

'./configure' '--enable-fpm' '--prefix=/usr/local/php7' '--with-config-file-path=/usr/local/php7/etc' '--with-config-file-scan-dir=/usr/local/php7/etc/php.d' '--enable-exif' '--with-gd' '--with-mysql' '--with-mysqli' '--with-pdo-mysql'

[注] centos自带5.3.3配置参数略,有点长,而且很多模块动态编译成动态加载模块,编译参数里是with-out,所以参数价值不大,故从略。
php7已经移除mysql模块,所以其配置参数里的 --with-mysql 事实上没用,在实际编译中被忽略掉的。

php-fpm配置

php-fpm全部配置成最大20进程,apache也配置成最大20个进程

测试说明

在本机上使用ab测试,减少网络传输的影响,500次连接,并发10,记录 Requests per second(req/s, 以下不再指明),示例

ab -c 10 -n 500 -H "Host: c.dom" http://127.0.0.1/phpinfo.php

[注] 因为使用虚假的域名,所以通过 -H参数指定主机名Host(改host文件也是一样的效果)

测试过程1:phpinfo页面

静态html基准测试,将phpinfo页面的输出保存成html文件,每秒稳定在3000次以上(300并发以下基本上能稳定在3000次,开ab的-k参数的情况下)

(phpinfo页面测试意义其实不大)

版本           次数1       次数2        次数3
---------     --------   --------    ----------
5.3模块:       810         837         774
5.6:          517         635         663
7.0b3:        675         700         638

这里看出php7的性能并不突出,反而apache模块运行效率更高

测试过程2:新安装wordpress文章页

新安装wordpress,其自带的一篇文章页http://127.0.0.1/wordpress/?p=1

版本          次数1        次数2        次数3       次数4
---------    --------    --------    ---------  --------
5.3模块:      7.00        7.06        6.84       6.91
5.6:         7.54        7.55        7.48       4.55
7.0b3:       10.12       10.38       10.14      10.47

[小结]:5.6 较5.3略有增强,但差别很小;但php7较都有显示提高。

测试过程3:wordpress导入一批文章后的文章页

导入一批文章后,该测试里增加php5.3.29的fast-cgi版本

ab -c 10 -n 500 -H "Host: c.dom" http://127.0.0.1/wordpress/?p=6459
版本         次数1      次数2       次数3      次数4      次数5    平均值
---------   ------    -------    --------   -------   -----   -----
5.3模块:     5.76      5.60       5.66       5.64      5.82    5.696
5.3 fpm:    5.86      5.97       5.91       6.11      5.97    5.964
5.6:        6.57      6.62       6.65       7.35      5.49    6.536
7.0b3:      8.73      8.33       9.02       9.00      8.67    8.750

[小结]:延续前面的结果,php7比5.x有30%-50%提升,效果明显。

另外5.3的fastCGI及模块差别可以忽略,似乎不像有人说的fastCGI效率有多高。

php7性能提升幅度,似乎也不像鸟哥Laruence所说的翻倍以上的提升(第45页片子)但30%+的提升,也足够让人欣喜了

测试结论

就前面做的测试来看,php7确实比5.x版本有明显提升,值得在生产环境中部署(暂不考虑兼容性)。然而说前面测试结果来看,

附记*php的后向兼容性

按官方文档所示,php7在语言核心方面,变化几乎忽略。主要是彻底放弃php5.4以来已经声明“过时”的特性。

已知可能有较大影响的是 mysql_* 函数被移除,这就意味着使用mysql_*的一些旧应用将无法在php7上跑!一个可选的解决方案是,使用fastCGI,多php版本共存,迁就这些旧应用。

apache下php版本共存,可以参考CentOS 6.x/apache 2.2下php多版本共存探索(模块及fastcgi)/mod_proxy_fcgi实现

CentOS 6.x/apache 2.2下php多版本共存探索(模块及fastCGI)/mod_fcgi,mod_proxy_fcgi实现

在apache下整合fastCGI模式运行的php-fpm,似乎网上很少相关材料,就连英文版材料也少。只要是php-fpm,基本上都是与nginx搭配。查了一大批相关资料,写本文总结一下。

apache下有多个fastCGI的支持方案:至少有mod_fcgimod_fastcgigit)、mod_proxy_fcgi等。这两个模块都有点老,尤其mod_fastcgi自从2007年以来就没有更新,略掉不谈,事实上没用过用。mod_proxy_fcgi模块是httpd 2.4+的版本正式引入,通过简洁的一行 ProxyPassMatch 指令即可。

mod_fcgi

mod_fcgi模块本身是做fastCGI进程管理的,使用它就不需要使用php-fpm管理进程了。核心配置参数

LoadModule fcgid_module modules/mod_fcgid.so
<VirtualHost *:80>
    DocumentRoot "/var/www/html/site_1"
    ServerName "www.yourhost.com"
    DirectoryIndex index.html index.php
    #php.ini的存放目录,Linux下通常不需要
    #FcgidInitialEnv PHPRC "D:/php"
    # 设置PHP_FCGI_MAX_REQUESTS大于或等于FcgidMaxRequestsPerProcess,防止php-cgi进程在处理完所有请求前退出
    FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000
    #php-cgi每个进程的最大请求数
    FcgidMaxRequestsPerProcess 1000
    #php-cgi最大的进程数
    FcgidMaxProcesses 3
    #最大执行时间
    FcgidIOTimeout 600
    FcgidIdleTimeout 600
    #php-cgi的路径
    FcgidWrapper /usr/local/php7/bin/php-cgi .php
    AddHandler fcgid-script .php
    FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 1000
    <Directory "/var/www/html/site_1">
        Options +ExecCGI
    </Directory>
</VirtualHost>

其中粗体着色是必须参数,其它几个Fcgid*指令,是优化之用,这里仅示例,要按实际情况调整数值。具体参看mod_fcgi官方文档

使用mod_fcgid的几个特点

  1. php-fgi进程是由apache模块启动并管理,不需要配置php-fpm
  2. 在php-cig进程以apache用户身份运行,php程序写的文件,其权限为apache用户(而不像php-fpm下写文件为php-fpm用户所有,默认是nobody),这样在目录权限管理方面一致性高些。

mod_fastcgi

虽然CentOS 6.x下是apache 2.2,但所幸已经有人成功移植: https://github.com/ceph/mod-proxy-fcgi 我们可以直接使用;更幸运的是它已经进入epel源,直接yum安装即可;不想匹配epel源的,直接下载rpm包安装也可以(示例 http://mirrors.ustc.edu.cn/epel/6/x86_64/

当然可以重新编译安装apache 2.4, 这样直接有mod_proxy_fcgi可以使用,但这里还是保持原版本不变,省掉编译的工作量。

参考mod_proxy_fcgi官方文档,整合php-fpm的配置指令

ProxyPassMatch "^/myapp/.*\.php(/.*)?$" "fcgi://localhost:9000/var/www/"

语法很简单,跟配置反向代理类似,可以按实际需要做修改。事实上与mod_proxy模块语法一致的,不同处是将http协议改成fcig协议。

以上是apache整合php-fpm模式运行的fastCGI,接下来要对yum安装的php做下配置修改。

yum安装的php配置文件 /etc/httpd/conf.d/php.conf ,其中有如下一行

AddHandler php5-script .php

我们要对不同的站点启用不同的php,上面一行是对全局的.php文件分配给php模块处理,我们把这一行注释掉。而是在每个站点启用不同的php运行模式。

以上即是处理方式。

[已知问题]:裸目录地址转发

有一个困扰的问题没有解决,感觉有点像模块bug:

对于配置了DirectoryIndex index.php的目录,如果其子目录没有index.php,上述ProxyPassMatch还是会做fastCGI转发,这时会看到php-fpm的404响应,而不是apache的响应403页面。但前面的规则并不转发这裸空目录的url,所以感觉像bug

再者就是,对于ProxyPassMatch匹配的目录,apache自动索引功能失效。(当然如果不开启autoindex就无所谓了。生产环境下通常不开启的)

其它,似乎也没有什么严重后果,或者我没还意识到(?)。

解决方法:每个目录下,都放置一个index.html,避免fpm-php处理空请求

 

php函数mult_iconv:转换任意维数组的字符集编码(扩展iconv函数功能)

php的iconv函数只支持对字符串的转换编码,如果是数组,就要自己遍历转换了,因此写如上的函数,对任意维数组进行转换,同时转换下标(索引)及值。

注意:不转对象。

function mult_iconv($in_charset,$out_charset,$data)
{
    if(substr($out_charset,-8)=='//IGNORE'){
        $out_charset=substr($out_charset,0,-8);
    }
    if(is_array($data)){
        foreach($data as $key => $value){
            if(is_array($value)){
                $key=iconv($in_charset,$out_charset.'//IGNORE',$key);
                $rtn[$key]=mult_iconv($in_charset,$out_charset,$value);
            }elseif(is_string($key) || is_string($value)){
                if(is_string($key)){
                    $key=iconv($in_charset,$out_charset.'//IGNORE',$key);
                }
                if(is_string($value)){
                    $value=iconv($in_charset,$out_charset.'//IGNORE',$value);
                }
                $rtn[$key]=$value;
            }else{
                $rtn[$key]=$value;
            }
        }
    }elseif(is_string($data)){
        $rtn=iconv($in_charset,$out_charset.'//IGNORE',$data);
    }else{
        $rtn=$data;
    }
    return $rtn;
}

下载程序文件(含示例)

调用示例:

$foobar=mult_iconv('gbk','utf-8','一个数组、字符串或其它类型数据');

一个复杂一点的测试示例(不转对象)

// ******* 一个复杂一点的测试示例 ********************
class MyClass
{
    public $v1='不转对象,恭喜发财';
    public $v2='skipped object';
    public function f()
    {
        return true;
    }
}
$obj=new MyClass();

$foo=array('abcd','随便写点文字'
    ,array('中文下标'=> 789,'天地玄黄'
        =>array('宇宙洪荒'=>'赵钱孙李',300=>'恭喜发财,不转对象'
                    ,array('更深的数组'=>'照样可以转换')
                )
    )
    ,'恭喜发财,不转对象' => $obj
    ,'如需转对象'=>'Do It Yourself!'
    ,'作者很懒'=>'用不到就不写了'
    );
$bar=mult_iconv('gbk','utf-8//IGNORE',$foo);
var_dump($bar);

php+MSSQL的坑:(n)varchar型字段被截断

很自虐的搭配php+MSSQL,太多的坑,就不说text型被截断了。

受限于现有的asp+mssql应用,新增的部分功能使用php开发。对一个表的读写,后台使用asp,读写都很正常。前台一个调用是php写的,但就是遇到一个诡异的问题,要对数据做一个很复杂的解析处理,结果是数据丢失一部分。一层一层的输出,最后才发现是从数据库读出来了数据就不完整,这可奇怪了。又不是text型的数据,加了ini_set()修正text型默认长度限制,也不行。

但被截断长度很奇怪,恰恰是254个字节,似乎正好是较老的mssql里varchar()的默认最大长度;而该字段的实际是varchar(1000);

难道是字段类型问题?

于是修改该字段为text型,再执行,全好了,没有一点异常。

看来php+mssql实在是个自虐的搭配,不知道还有多少坑....

不过限于老的程序架构,也是个没办法的,人总是要吃饭的....

[另记: 盘点php+mssql下的坑]

这些坑还是有解决方案的,先留着,以后补充

1 text/ntext型字段长度被截断

2 php下mssql 库不支持ntext类型的数据

3 “varchar(n) 其中n>254 ”类型数据被截断

4 php5.3以后的win32 官方二进制版不支持mssql库

折腾:vps上php环境升级为php5.5

php5.5出来很久了,一直没应用,vps上还是5.3,折腾一番尝试一下看5.5效果如何。

查阅了官方的升级说明,从5.3到5.5变化不大,而且vps上主要跑的wordpress,drupal,phpmyadmin等应用,它们的开发理论是是比较规范的,估计问题不大。

原环境,php-fpm, nginx, 其中php安装了apc, memcache两个附加模块。

下载php5.3源码,解压,参考5.3的配置参数,改了下安装目录到/usr/local/php55,编译安装,很顺利。

不过启动php-fpm进程时,还得加 -c参数指定php.ini目录才行,指定该参数重新配置编译了几次,都还是不行。那就带参数也无所谓了。

在一个测试站点上,修改nginx里fast-cgi端口为9005, 新开启一下fpm进程,php-fpm端口设置为9005,(php5.3工作在9000端口)这样不影响php5.3的正常工作。打开phpinfo页面,检查没有发现异常,打开phpMyAdmin,也正常。

编译附加模块apc,但编译失败,google到雪鸟(雪候鸟)的文章,说php5.5里集成了zend O+加速模块,这样就可以不要apc了。

到以前的memcache目录里,重新配置编译安装,正常。

加载,因为是偷懒从php5.3的php.ini里拷来加载模块的两行代码,没有改,在运行php-fpm时报错了,说是模块跟php的api版本不一致,一个是2009xxx版,一个是2012xxx版,以为编译错了。重新下载新版本memcache也一样。

纳闷中,突然意识到php.ini里最后加的加载memcache模块是以绝对路径调用的,这个路径没改,还是加载的php5.3目录下的,这不报错就没天理了。删掉路径,只保留文件名,杀死php-fpm进程,重新开启,正常了。这次安装模块是安装到extension_dir指定的目录下的,这样更简单。

运行wordpress站点,报错了:

syntax error, unexpected end of file

想起php.ini里没有开启short_open_tag, 以前安装5.3时也报了这个错误,一些不规范的插件,不想改它的源码,反正有其它一些php程序也这么干,那就打开short_open_tag好了。

重启php-fpm,运行wp又报错了

Call-time pass-by-reference has been removed

又是一个插件的问题:wp-related-posts,其源码 wp-related-posts/wp-relatedposts.php 里有这样的行 wp_relatedposts_ontags(&$options), 删除调用参数时的&号,即wp_relatedposts_ontags($options) 这就好了。

测试运行没有发现问题。

杀死php5.3的fpm进程。修改php5.5的fpm到9000端口上,并启动。

再测试一番,正常。

修改/etc/rc.local里的php-fpm开机启动命令为5.5版本。

完成。

记录一下,算是这个中秋节做的一点有意义的事情。

原计划一大早睡觉,结果又0:18了——

---- 130923 补 --------------------

原来 opcache并没有自动加载,虽然它会被安装到php扩展的目录下,默认在 {$PREFIX}/lib/php/extensions/no-debug-non-zts-20121212

在php.ini里加入以下两行

[opcache]
zend_extension=opcache.so

opcache.so是个zend扩展模块,要用zend_extension=xx加载。

重启php-fpm生效

php在中url处理方面很有用的几个函数

http_build_query

(PHP 5) http_build_query — 生成 URL-encode 之后的请求字符串

<?php
$data = array('foo'=>'bar',
'baz'=>'boom',
'cow'=>'milk',
'php'=>'hypertext processor');
echo http_build_query($data); // foo=bar&baz=boom&cow=milk&php=hypertext+processor
?>

compact

array compact ( mixed $varname [, mixed $... ] )

(PHP 4, PHP 5)  compact — 建立一个数组,包括变量名和它们的值

<?php
$city  = "San Francisco";
$state = "CA";
$event = "SIGGRAPH";
$result = compact("city", "state", "event");
// array('city'=>'"San Francisco"','state'=>'CA','event' => "SIGGRAPH")
?>

-------------

$qs=compact('province','city','name');
foreach($qs as $key => $value){
    if(!$value){
        unset($qs[$key]);
    }
}
$url='something/search/?'.http_build_query($qs) ;