-
php里为file_get_contents等的http请求设置默认超时时间
发表于 2011年11月22日 没有评论由于file_get_contents($url)的抓取方式是如此的简单易上手，并通常表现良好，在php世界里受到了相当的好评，并被大量的……滥用。
最常见的问题是，你要取的内容在一台不稳定的服务器上，或者是网络不稳定时，这个函数的响应时间从常规的100ms级跃升至秒级。悲催的是，这种情况可是能轻易的毁掉一个中型网站的。而且，除了连接数耗尽的可能外，还可能会导致CPU 100%占用，张宴的《PHP-CGI 进程 CPU 100% 与 file_get_contents 函数的关系》里提到过这个问题。
设置$context参数确实是一个比较恶心的事，特别是维护一个到处都有这个破调用的系统时。好在，我们还是有简单的解决办法的，那就是通过PHP 5.1.0新引入的函数stream_context_get_default来设置stream_context的缺省值。这样的话只要在公共的include文件中放置以下代码就能解决问题了：
define('HTTP_STREAM_TIMEOUT', 2); $old_context_opts = stream_context_get_default(); stream_context_set_option($old_context_opts, 'http', 'timeout', HTTP_STREAM_TIMEOUT); stream_context_get_default($old_context_opts);其中HTTP_STREAM_TIMEOUT是超时的秒数，之所以没有用毫秒是因为stream_context本来就不能设置到这个级别的超时时间。
另外，从PHP 5.3.0开始，stream_context_set_default可以直接做到以上效果，不再需要别扭的用get函数来设置缺省值了。同时，以上方法也适用于设置proxy等其他属性。
相关日志：
-
改用php-fpm+eAcclerator替代spawn-fcgi+xcache跑wordpress
发表于 2010年03月16日 没有评论
VPS上一直用的是Nginx + PHP FastCGI，其中FastCGI是用Lighttpd的spawn-fcgi来做管理，稳定性上面倒没什么可挑剔的，一直很正常，就是有一点很不好，三到五天就会出现一次PHP把内存吃光的情况。 VPS是384M的内存，1G+的交换文件，理论上5个Nginx进程加上8个PHP FastCGI是不该超出的，但连虚拟内存都吃光的情况还真出现过。 每次都是ssh连上以后盲敲指令killall php-cgi解决。碰了两三次后索性写了段shell到crontab里缓解此问题，具体作用是每小时的13分和43分检查并杀掉内存占用过多的处于休眠状态的PHP FastCGI进程：
13,43 * * * * ps aux|grep php-cgi|awk '(($5>150000||$6>60000)&&$8=="S"){print $2}'|xargs kill -9
查了php.ini中内存限制的配置和xcache的相关配置，算下来的最大内存总占用应该是在500m内的，这还是因为XCache未能实现opcode的共享存储，导致重复占用的缘故。 这里要特别提一下，这个问题是因为内存地址映射关系在多进程中的复杂性所造成的，XCache和APC都没解决，最近刚发现最新版本的eAcclerator已解决了此问题，这次也一起更换了opcode cache模块。
一开始怀疑是PHP自身的内存管理问题，但一来公司的mod_php同版本代码并未出现该问题，另外同VPS上另一个用户所启动的PHP FastCGI进程却也并未出现该问题。 经粗略的排查，发现当大量使用WordPress中后台的各类功能后内存占用会急剧狂飙，但未安装任何插件的干净的WordPress则无此问题。 由于机器上不止一份WordPress实例，而且插件众多，难以一一排查，只好从PHP自身来考虑解决此问题。
首先尝试的是将PHP替换为5.2.13和5.3.2分别测试过，不过问题依旧。倒是用5.2.13换了php-fpm来启动后解决了该问题。
安装方法很简单，在php源码目录下执行以下指令：wget http://php-fpm.org/downloads/php-5.2.13-fpm-0.5.13.diff.gz
gzip -dc php-5.2.13-fpm-0.5.13.diff.gz | patch -p1随后在原来的配置参数后面加上--enable-fpm重新make && make install就可以了。
更新php后也用eAccelerator替换掉了XCache，随后查看运行状况，问题确实得到了解决，虽然不确定到底是由于php-fpm还是eAccelerator，但可以确定的是eAccelerator在FastCGI的模式下，其opcode cache确实可以通过shm共享。
更换php-fpm带来的也不仅仅是这样的好处，当你升级php或者是更改php.ini时，它可以平滑的关闭老进程并启动新进程使服务持续可用，此外还可以根据目前的服务压力，动态的增加或者减少PHP FastCGI进程的数量。 更多的信息可以猛击这里（php-fpm文档中文翻译），英文好的同学则建议猛击这里查看原文。
使用过程中多次刷新查看phpinfo，并利用空延迟脚本使执行落在不同的php-cgi进程上，证实其缓存确实是放在共享内存中。
附上一张eAccelerator的使用情况截图：
相关日志：
-
解决Zend Optimizer无法加载及与eAccelerator的冲突
发表于 2010年03月16日 没有评论
在VPS上下载了3.3.9的Zend Optimizer，找说明安装后出现错误：
cannot restore segment prot after reloc: Permission denied
找了下，问题是出在SELinux上，关闭SELinux即可解决：
- 修改/etc/sysconfig/selinux，修改为SELINUX=disabled
- 执行/usr/sbin/setenforce 0立即关闭，且无需重启系统
如果你不希望关闭SELinux的话，也可以
chcon -t shlib_t ZendOptimizer.so
chcon -t texrel_shlib_t ZendOptimizer.so
操作后php-fpm start启动，一切正常。 但ShopEx网站返回502错误，修改php.ini输出错误日志查看后发现访问Zend Guard做了encode的php文件均无法正常执行，错误是Connection reset，但命令行查看php -v时显示Zend Optimizer已加载，phpinfo()也显示正常。
反复尝试多次后发现是装载次序的问题，修改php.ini，使eAccelerator在Zend Optimizer之前装入即可。相关日志：
-
给某网站Windows主机下Discuz!论坛的一些优化建议
发表于 2010年01月6日 2 条评论
近期由于网络方面的问题，该网站双线之一被和谐，故此另外一条线路承受了过多的压力，时不时会出现以下的错误：
看到之后第一反应是调整MySQL连接数，这个数字可以通过show variables like 'max_connections';获得，并在my.cnf中修改。（根据错误的出现频度，下面例子中的数字建议修改为服务器上当前设置的2倍为宜）
[mysqld]
set-variable=max_connections=500相关日志：
最近评论