如何避免CGI超时?
我有一个用户在浏览器中运行的 PHP 进程,但往往需要相当长的时间 - 最多 5 分钟。我们刚刚切换到新服务器,当我们现在尝试运行该脚本时,它总是在 4 分钟时超时,发送到 500 内部服务器错误页面并在错误日志中输出以下错误:
等待 CGI 输出超时 脚本
脚本标题过早结束: cgi_wrapper
有趣的是 PHP 进程似乎确实在后台完成。如果我们离开 500 错误页面并稍等一下,就会对脚本进行所需的更改。
有什么办法可以解除这个似乎对我们施加的 CGI 限制吗?我已经阅读过有关 FastCGI 的内容,但不确定如何在我们的服务器上安装它(Apache、centOS、PHP 5.3)。
感谢您的帮助!
I have a PHP process which the user runs in the browser, but tends to take a fairly long time - upwards of 5 minutes. We just switched to a new server, and when we try to run the script now, it consistently times out at 4 minutes exactly, sending to a 500 Internal Server Error page and outputting the following errors in the error log:
Timeout waiting for output from CGI
scriptPremature end of script headers:
cgi_wrapper
What's interesting is that the PHP process does seem to complete in the background. If we navigate away from the 500 Error page and wait a bit, the desired changes from the script do get made.
Is there any way to unhinge this CGI limit which seems to have been placed on us? I have read about FastCGI, but am not sure how to install this on our server (Apache, centOS, PHP 5.3).
Thanks for your help!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
可能是 Web 服务器在等待脚本响应时超时。其实等了四分钟,服务员看起来还是很有耐心的。 FastCGI 连接的默认值为 30 秒。
它可能有助于在客户端等待时向其发送(和
flush()
ing)一些数据。这告诉 Web 服务器和浏览器该请求仍然有效。例如,如果您的脚本最后提供 HTML 页面,您可能会不时发送
无论如何,任何需要超过 10 秒才能完成的脚本都是糟糕的设计。我建议在单独的进程中在后台完成这项工作,并让客户端轮询完成状态。请注意,无论您在服务器上执行什么操作,某些浏览器/代理都可能会使请求超时。
Probably the web server times out waiting for a response from the script. Actually with four minutes the server seems to be pretty patient. The default for FastCGI connections is 30 seconds.
It may help sending (and
flush()
ing) some data to the client while he is waiting. This tells both the web server and the browser that the request is still alive.For example, if your script serves a HTML page at the end you may send a
<!-- please wait... ->
from time to time. It won't be visible to the user.Anyway, any script that takes more than 10 seconds to complete is bad design. I suggest doing that work in the background in a separate process and have the client poll the completion status. Be aware that some browsers / proxies may time out the request no matter what you do on the server.