清晰的代码如下：

看到了么 截图中说的是PHP脚本最大的执行时间。那么这个时间可以通过PHP.ini或者用PHP函数设置处理。

但是 我们经常能看到 504（503是网关处理问题，504是网关响应超时问题，有可能是响应缓存区过小或者是程序进程执行时间限制）超时的页面，这是怎么回事呢？两者是有区别的。

绝逼是 浏览器太长时间没有得到返回的响应（因为请求还没结束），报网关超时。那么这种页面情况下，还没超时的PHP运行脚本还在执行么？答案是肯定的，还在执行(此处有待证实，有可能是SQL的执行队列还没执行完)。（执行大量数据库插入语句程序时验证得出，包括关闭浏览器后数据还在执行插入）。

那么问题来了。如果执行脚本的时间设置了足够大，那么PHP 会不会有其他服务器配置来限制程序的执行时间。那么响应超时默认时间又是多少呢？

访问一个php页面，过一会儿就显示504，这时候php程序还会继续执行吗？网络上的答案：

要看错误的类型是致命错误还是警告性错误，如果是致命性错误，程序直接终止运行，其他一律正常往下执行！！

那么出现 504 怎么处理呢？网络上又给出了答案：

一般看来, 这种情况, 这将,现在的网站, 尤其某些论坛有大量的回复和很多内容的, 一个页面甚至有几百K默认的fastcgi进程响应的缓冲区是8K, 我们可以设置大点在nginx.conf里, 加入:

这表示设置fastcgi缓冲区为8×128k当然如果您在进行某一项即时的操作, 可能需要, 例如设置成60秒:

我只是调整了这两个参数, 结果就是没有再显示那个超时, 可以说效果不错

另一篇文章首先是更改php-fpm的几处配置：把由之前的10改为现在的30，这样就可以保证 有充足的php-cgi进程可以被使用；把由之前的0s改为60s，，可以防止进程都被挂起，提高利用效率。接着再更改nginx的几个配置项，：fastcgi_buffers由 4 64k 改为 2 256k； fastcgi_buffer_size 由 64k 改为 128K； fastcgi_busy_buffers_size 由 128K 改为 256K； fastcgi_temp_file_write_size 由 128K 改为 256K。好了，重新加载php-fpm和nginx的配置，再次测试，至今两周时间内没有再出现504 Gateway Time-out的情况，算是达到效果了。另外，php-fpm的默认静态处理方式会，这也是导致nginx出错的原因之一，因此可以将php-fpm的处理方式改成apache模式。 apache-like

】

综上，导致的原因可能是fastcgi进程响应的缓冲区太小，php-cgi的进程长期占用内存，php-cgi进程 处理脚本的超时时间。

通过配置服务器的相关参数可以缓解。

那么问题又来了，很多时候我们都是虚拟主机没有配置权限。那执行大数据量的循环处理插入数据库操作怎么办？经常出现504页面，那么还好吧，按理你出现504只是响应超时，而程序还是在哇哇滴跑的。可是你别忘了，

我们还有个 缓存区后者处理脚本的超时时间。那么如果是这个超时那么是不是程序就挂了（没法执行完毕）。

天呐，我的插入执行语句只执行了1000条就停了，本来要执行20000条的。这个时候有个问题（程序进程是真的停了么还是内存满了被挂起稍后执行，挂起的是19000还是2000呢，反正暂时肉眼可见数据没有执行插入了）。

疑问来了，是不是这个问题导致 504错误然后程序还在执行或者挂起（其实还有可能是MYSQL收到SQL指令但是语句还在队列中排队执行未完毕二第二次的判断过滤和请求就来了，导致重复插入），尽管我们分配次处理并每次都用数据库是否已存在该条数据判断后过滤再执行插入，但是还是出现过滤没有成功，重复执行插入记录的情况。（即上次的程序还没执行完毕就开始执行第二次的，第二次的判断出没有记录所以准备执行插入，但是第一次也在同时执行余下的同条插入语句）。

综上，那有没有其他方式去解决这种大量插入呢？

让每次都正常响应后，可得到echo（判断一次大概能成功执行多少条，控制执行条数）再执行第二条请求（把握好执行条数，不要让程序504后程序不可控）

直接数据库客户端执行语句（很多时候不适用，因为需要处理业务逻辑代码）

程序休眠只会缓解内存等问题还是有可能导致 超时 后进程不可控的

如果涉及多事务，开事务来处理会更慢。

循环处理的代码参考（有重复插入问题的）

* 会员加积分

*/

function add_point(){

set_time_limit(0);

$model = D('Member');

$field = 'member_id,member_name,member_points';

//$member_arr       = $model->join('left join sto_points_log on sto_points_log.pl_memberid = sto_member.member_id')->where('sto_points_log.pl_stage != "callback"')->group('member_id')->field($field)->select();

$member_arr = $model->query("SELECT member_id,member_name,member_points FROM sto_member WHERE member_id   ");//过滤

$model_point_log = M('points_log');

$n = 0;

$num = 1;

//$model->startTrans();

foreach((array)$member_arr as $k=>$v){

$arr = array();

$arr['pl_memberid'] = $v['member_id'];

$arr['pl_membername'] = $v['member_name'];

$arr['pl_points'] = 5000;

$arr['pl_addtime'] = time();

$arr['pl_desc'] = '十八洋系统回馈老用户';

$arr['pl_stage'] = 'callback';

$point_log_arr = $model_point_log->field('pl_id')->where('pl_memberid = '.$v['member_id'].' and pl_stage = "'.'callback'.'"')->select(); 

if(count($point_log_arr) > 0){

//

continue;

}

$rt = $model_point_log->add($arr);

if($rt !== false){

$arr_save['member_points'] = $v['member_points'] + 5000;

$rtt = $model->where('member_id='.$v['member_id'])->save($arr_save);

if($rtt !== false){ 

//$model->commit();

//$model->startTrans();

$n++; $num++;

echo '成功处理'.$n.'条数据 ！/r/n';

}

}

}

}

//$model->commit();

}