Php 导致超时的脚本

我有一个脚本，导致超时，有时。运行需要一段时间，我将解释它的作用： 我们的用户数量相当少（假设为20），我们管理所有这些用户的库存。库存由第三方每天早上（比如早上6点左右）通过ftp以.csv文件的形式发送。清单包括项目描述，然后是图像URL的可变长度列表。 我们的系统需要下载它还没有的任何图像（99.9%的时间只有在库存提要中有新项目时才会发生）。通常，库存饲料95%相同，因为大部分库存从一天到下一天都不销售

棘手的是，每天早上，我们的系统都会查看每个库存商品，并对照新的提要交叉检查每个商品的图像列表。如果图像不存在，它会使用CURL操作将新图像带过来

正如你所想象的，这可能是一个相当耗时的操作，具体取决于当天的情况。我有一个cron任务。如果我手动运行它，它需要1-5分钟，这取决于负载，有时（如每5次尝试一次），它会给出一个“内部服务器错误”，没有任何解释

我首先在文件中使用set_time_limit（0）指令，所以我想知道是否还需要执行其他操作来确保它不会超时？或者你们认为失败的传输有可能在某些情况下导致问题并导致脚本死亡？比如一次失败的转会，处理得很糟糕，我不知道。与其发布所有代码，我想知道我是否可以先得到一些想法，因为脚本非常复杂，我不想浪费任何人的时间

欢迎提出任何意见。我想不出为什么它间歇性地不工作。

---

记录在案，如果我手动运行两次，第二次总是有效的，但我认为这是因为第一次运行已经处理了大部分下载…

一些主机在没有设置时间限制的情况下杀死长时间运行的任务。试着联系他们并询问相关情况。

检查日志以了解ISE的确切错误。这可能会导致您检查PHP日志，这取决于系统设置以获得更有限的错误。在没有任何日志的情况下猜测问题，只能与最佳猜测一样好

---

图像的文件大小是多少？不知何故，我认为这可能是由于传输失败，我自己。

“内部服务器错误”，比如发生500次错误时服务器会吐出什么？这些都会被记录在服务器的错误日志中，比客户端提供的要详细得多。我是主机。。。哈哈。所以我的php.ini被设置为30秒，但我认为如果设置时间限制，它会覆盖ini指令？max\u input\u time被设置为60——这会影响curl ops吗？我在网上资源中找不到任何关于它的信息……这些图片一般都在500k以下。600x800 powershot-ish照片，非常标准。没错，但我想这也取决于传输速率、响应时间和所有有趣的东西。你检查过错误日志了吗？我觉得你正在从中检索图像的站点有问题，你可能也想检查一下。