脚本执行太耗时

‘壹’ php执行cmd脚本超时，不能去改ini因为超时期间页面一直在等待，怎么才能

PHP脚本执行超时的解决办法

在php中默认脚本执行超时时间为30秒了，如果未进行设置30秒之后如果你的脚本还未执行完就会超时了，下面我来给大详解解决PHP脚本执行超时的方法。
php.ini 中缺省的最长执行时间是 30 秒，虽然可以通过调整 php.ini 中 max_execution_time的值来达到目的，但有些情况是没有条件修改php.ini的，如何解决这个问题呢。
一种方法是在 PHP 脚本中加入
代码如下
ini_set('max_execution_time', '0');
将运行时间设置成0（无限值）；
另一种方法是在命令行下执行脚本，使用命令行执行脚本时，最大运行时间被设置为了无限值。
修改php.ini的脚本执行时间限制
编辑php.ini，修改max_execution_time值：
代码如下
max_execution_time=500
//此修改需要重新加载php.ini，需要重启web服务器生效。
通过.htaccess 文件设置脚本执行时间
代码如下
php_value max_execution_time 500
在脚本中设置执行的最大时间
代码如下
ini_set('max_execution_time', 500);
用php的函数取消脚本的时间限制
代码如下
set_time_limit(0);
set_time_limit用来设置脚本的超时时间，此函数规定从该句运行时起程序必须在指定秒数内运行结束，超时则程序出错退出。
下面是一个例子. 有10000条数据, 要修改其中某些数据, 运用PHP分步执行处理, 代码如下:
action.php
代码如下
<?php
$stid = isset($_GET['stid'])?$_GET['stid']:0;
$endid = $stid + 100;
$maxid = 10000;
function dosomething(){
//要时间比较多的操作
……
}
$sql_string=”select * from `table` where id>’$stid’ and id<=’$endid’ order by id”;
$datas = getdata_bysql($sql_string);
foreach($datas as $data){
//处理数据
…..
echo $id.” 处理完成. <br />”;
if($id>=$maxid){exit;}
}
if($stid<=$maxid){
$stid = $stid + 100;
$url=”action.php?stid=$stid”;
echo $url;
echo ‘<script language=”javascript”>location=”‘.$url.’”; </script>’;
}
?>
其中的dosomething()是一个耗时操作. 这里我们通过限制id范围来减少运行时间, 运行完后通过javascript的跳转来自动运行下一步
现在dedecms生成html页面时就是这样做

‘贰’ 如何使用Docker构建运行时间较长的脚本

问题
让我们从这个我试图解决的问题开始。我开发了一个会运行很长时间的构建脚本，这个脚本中包含了很多的步骤。
这个脚本会运行1-2个小时。
它会从网络下载比较大的文件（超过300M）。
后面的构建步骤依赖前期构建的库。
但最最烦人的是，运行这个脚本真的需要花很长的时间。
文件系统是固有状态
我们一般是通过一种有状态的方式与文件系统进行交互的。我们可以添加、删除或移动文件。我们可以修改文件的 权限或者它的访问时间。大部分独立的操作都可以撤销，例如将文件移动到其它地方后，你可以将文件恢复到原来的位置。但我们不会通过快照的方式来将它恢复到 原始状态。这篇文章我将会介绍如何在耗时较长的脚本中充分利用快照这一特性。
使用联合文件系统的快照
Docker使用的是联合文件系统叫做AUFS（译者注：简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统）。联合文件系统实现了Union mount。顾名思义，也就是说不同的文件系统的文件和目录可以分层叠加在单个连贯文件系统之上。这是通过分层的方式完成的。如果一个文件出现在两个文件系统，那最高层级的文件才会显示（该文件其它版本也是存在于层级中的，不会改变，只是看不到的）。
在Docker中，每一个在Union mount转哦给你的文件系统都被称为layers（层）。使用这种技术可以轻松实现快照，每个快照都是所有层的一个Union mount。
生成脚本的快照
使用快照可以帮助构建一个长时运行的脚本。总的想法是，将一个大的脚本分解为许多小的脚本（我喜欢称之为 scriptlets），并单独运行这些小的脚本，脚本运行后为其文件系统打一个快照 （Docker会自动执行此操作）。如果你发现一个scriptlet运行失败，你可以快速回退到上次的快照，然后再试一次。一旦你完成脚本的构建，并且 可以保证脚本能正常工作，那你就可以将它分配给其它主机。
回过头来再对比下，如果你没有使用快照功能了？当你辛辛苦苦等待了一个半小时后，脚本却构建失败了，我想除了少部分有耐心的人外，很多人是不想再来一次了，当然，你也会尽最大努力把系统恢复到失败前的状态，比如可以删除一个目录或运行make clean。
但是，我们可能没有真正地理解我们正在构建的组件。它可能有复杂的Makefile，它会把把文件放到文件系统中我们不知道的地方，唯一真正确定的途径是恢复到快照。
使用快照构建脚本的Docker
在本节中，我将介绍我是如何使用Docker实现GHC7.8.3 ARM交叉编译器的构建脚本。Docker非常适合做这件事，但并非完美。我做了很多看起来没用的或者不雅的事情，但都是必要的，这都是为了保证将开发脚本的总时间降到最低限度。构建脚本可以在这里找到。
用Dockerfile构建
Docker通过读取Dockerfile来构建镜像。Dockerfile会通过一些命令来具体指定应该执行哪些动作。具体使用说明可以参考这篇文章。在我的脚本中主要用到WORKDIR、ADD和RUN。ADD命令非常有用因为它可以让你在运行之前将外部文件添加到当前Docker镜像中然后转换成镜像的文件系统。你可以在这里看到很多scriptlets构成的构建脚本。
设计
1. 在RUN之前ADD scriptlets
如果你很早就将所有的scriptletsADD在Dockerfile，您可能会遇到以下问题：如果你的脚本构建失败，你回去修改scriptlet并再次运行docker build。但是你发现，Docker开始在首次加入scriptlets的地方构建！这样做会浪费了大量的时间并且违背了使用快照的目的。
出现这种情况的原因是由于Docker处理它的中间镜像（快照）的方式。当Docker通过Dockerfile构建镜像时，它会与中间镜像比较当前命令是否一致。然而，在ADD命令的情况下被装进镜像的文件里的内容也会被检查。如果相对于现有的中间镜像，文件已经改变，那么Docker也别无选择，只能从这点开始建立一个新的镜像。因为Docker不知道这些变化会不会影响到构建。
此外，使用RUN命令要注意，每次运行时它都会导致文件系统有不同的更改。在这种情况下，Docker会发现中间镜像并使用它，但是这将是错误的。RUN命令每次运行时会造成文件系统相同的改变。举个例子，我确保在我的scriptlets我总是下载了一个已知版本的文件与一个特定MD5校验。
对Docker 构建缓存更详细的解释可以在这里找到。
2.不要使用ENV命令来设置环境变量，请使用scriptlet。
它似乎看起来很有诱惑力：使用ENV命令来设置所有构建脚本需要的环境变量。但是，它不支持变量替换的方式，例如 ENV BASE=$HOME/base 将设置BASE的值为$HOME/base着很可能不是你想要的。
相反，我用ADD命令添加一个名为set-env.sh文件。此文件会包含在后续的scriptlet中：
THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env-1.sh
如果你没有在第一时间获取set-env.sh会怎么样呢？它很早就被加入Dockerfile并不意味着修改它将会使随后的快照无效？
是的，这会有问题。在开发脚本时，我发现，我已经错过了在set-env.sh添加一个有用的环境变量。解决方案是创建一个新的文件set-env-1.sh包含：
THIS_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
source $THIS_DIR/set-env.sh
if ! [ -e "$CONFIG_SUB_SRC/config.sub" ] ; then
CONFIG_SUB_SRC=${CONFIG_SUB_SRC:-$NCURSES_SRC}
fi
然后，在所有后续的scriptlets文件中包含了此文件。现在，我已经完成了构建脚本，我可以回去解决这个问题了，但是，在某种意义上，它会破坏最初的目标。我将不得不从头开始运行构建脚本看看这种变化是否能成功。
缺点
一个主要缺点是这种方法是，所构建的镜像尺寸是大于它实际需求的尺寸。在我的情况下尤其如此，因为我在最后删除了大量文件的。然而，这些文件都仍然存在于联合挂载文件系统的底层文件系统内，所以整个镜像是大于它实际需要的大小至少多余的是删除文件的大小。
然而，有一个变通。我没有公布此镜像到Docker Hub Registry。相反，我：
使用docker export导出内容为tar文件。
创建一个新的Dockerfile简单地添加了这个tar文件的内容。
产生尺寸尽可能小的镜像。
结论
这种方法的优点是双重的：
它使开发时间降至最低，不再做那些已经构建成功的子组件。你可以专注于那些失败的组件。
这非常便于维护构建脚本。构建可能会失败，但只要你搞定Dockerfiel，至少你不必再从头开始。
此外，正如我前面提到的Docker不仅使写这些构建脚本更加容易，有了合适的工具同样可以在任何提供快照的文件系统实现。

‘叁’ php进程超时接口返回504错误分析

在一次接口测试中，发现返回的http 504 time out 的错误，然后查看了php-fpm的错误日志，发现了如下错误

从表现上看，是php进程超时导致的进程被kill了，那么这个超时时间以及kill的机制是跟哪些参数有关呢，这里系统这里一下。

Nginx服务一般因为php的错误或者超时会有两种错误码502 bad Gateway 或者 504 Gateway Time-out

一种情况是php产生了语法错误，比如循环调用、变量作用域错误、方法不存在等，如果开启错误日志输出的话，这种错误在php-fpm的错误日志中是可以看到调用栈信息的。

另外一种情况可能就是超时引起的php-fpm主动kill的情况，在php.ini和php.fpm中有两个配置项，用来管理php脚本的最大执行时间

当php脚本的执行时间超过这个时间时，PHP-FPM不只会终止脚本的执行，还会终止执行脚本的Worker进程。所以Nginx会发现与自己通信的连接断掉了，就会返回给客户端502错误。

以顶部的错误为例，当报502错误是，nginx的errorlog中有如下日志，：

所以只需将这两项的值调大一些就可以让PHP脚本不会因为执行时间长而被终止了。request_terminate_timeout可以覆盖max_execution_time，

所以如果不想改全局的php.ini，那只改PHP-FPM的配置就可以了。

此外要注意的是Nginx的upstream模块中的max_fail和fail_timeout两项。这两个配置表示在fail_timeout事件内，如果fail的测试达到max_fail，那么在接下来的fail_timeout时间内，Nginx都会认为上游服务器挂掉了，都会返回502错误。

所以可以将max_fail调大一些，将fail_timeout调小一些。

PHP-FPM设置的脚本最大执行时间已经够长了，但执行耗时PHP脚本时，发现Nginx报错从502变为504了。这是为什么呢？

因为我们修改的只是PHP的配置，Nginx中也有关于与上游服务器通信超时时间的配置

以Nginx超时时间为90秒，PHP-FPM超时时间为300秒为例，报504 Gateway Timeout错误时的Nginx错误访问日志如下：

调高这三项的值（主要是read和send两项，默认不配置的话Nginx会将超时时间设为60秒）之后，504错误也解决了。

而且这三项配置可以配置在http、server级别，也可以配置在location级别。担心影响其他应用的话，就配置在自己应用的location中吧。

要注意的是factcgi_connect/read/send_timeout是对FastCGI生效的，而proxy_connect/read/send_timeout是对proxy_pass生效的。

参考链接： http://www.cnblogs.com/fei33423/p/8184098.html 感谢分享！

‘肆’ Active Server Pages 错误 'ASP 0113' 脚本超时/Default.asp 超过了脚本运行的最长时间

若你的脚本有耗时的操作则可以通过 Server.ScriptTimeout 属性更改脚本超时时间。

ScriptTimeout 默认值是 90 秒，一般情况下脚本的执行不应该会超过 90 秒，可能你的 ASP 程序里面有的死循环（或多余循环）之类，请仔细检查程序。

最常见死循环是在遍历 ADO 结果集时发生，例：
Do Until rst.EOF
Response.Write rst(0)
'rst.MoveNext '此处忘记了调用 MoveNext 方法，导致死循环。
Loop