只是好奇我如何判断这方面的表现。我们正在通过基于 PHP/Postgresql 的产品/购物网站运行 Apache。
我们有 2 台服务器 - 一台用于网站（PHP 脚本，所有静态内容），一台用于数据库。
我们的订单通过远程支付网关运行，如下所示：1. 客户在网络服务器上完成结账2. 然后客户被重定向到支付网关进行付款。3. 然后向我们的网络服务器脚本（从支付网关）发送通知，通知我们订单状态。此时，我们检查付款是否成功，然后相应地向客户的库存系统下订单。
现在，在步骤 3 中，我们遇到需要执行一些任务的情况，暂停 60 秒（这是客户端库存预订系统的自定义解决方法，直到将来稍后升级），然后继续执行其余任务。"暂停 60 秒"是我不确定的部分。脚本需要等待一段时间（一分钟），然后我们执行其他任务（将订单转移给我们的客户）。
我可以通过两种方式考虑这样做：
a） 我们在 PHP 脚本上设置 60 秒的超时/间隔，然后完成作业。这可能不可行，因为我们正在处理支付网关，我们不知道它们是否会超时或这里是否会发生任何问题。
或
b） 我们执行第一轮任务，然后，cron 每 60 秒运行一次以检查未完成的订单传输，然后为我们进行平衡工作。cron 需要每 60 秒运行一次，以捕获要发送到客户端的订单。
Web服务器有许多crons正在运行，主要是在非高峰时间。谁能建议：
-
如果您能看到上述不同的解决方案
-
如果您同意解决方案 b），这会不会对我们的网络服务器造成某种过载？我判断这一点的最好方法是什么？任务本身并不苛刻（检查数据库，在我们的 Web 服务器上将文件从一个地方传输到另一个地方），但我想知道 cron 是否应该像这样每分钟执行一次。
谢谢里希
鉴于您的约束和时间安排，为什么不编写一个系统守护程序来完成这项工作呢？它可以"一直"运行，在没有工作时睡觉，并根据需要经常醒来。它还避免了"我有 5 个正在运行"的问题。正如约翰所说，你可以建立一个队列，并跟上它。我已经成功做了几次。
答案是 B。 如果您担心服务器在分钟级别的时间间隔内的性能，那么您实际上只需要更大的机器/更丰富的架构。 Web 服务器上的大多数性能问题都归结为更精细级别的使用峰值。
如果您担心，解决方案非常简单。 与其每分钟愚蠢地启动一堆进程，不如构建一个队列和一些状态管理。 启动队列时将计算机标记为"正在处理"。 如果 cron 再次触发并且机器仍在"处理"，那么只需转储并等待下一个即时报价。 完成队列后，取消标记计算机。
如果你在没有突破"处理"的情况下进行 3-4 次刻度，那么你可以调用某人的寻呼机。