PHP 睡眠和循环期间的内存使用情况

发布于 2024-10-24 08:01:10 字数 779 浏览 1 评论 0原文

我有几个关于 PHP 内存使用的问题。我将自己进行一些测试,但获得各种建议非常有帮助。

我最近了解了 PHP 函数ignore_user_abort(),它允许脚本在用户关闭页面时继续运行。我正在考虑将其用于我的电子邮件新闻通讯工具而不是 Cron 作业,因为配置 Cron 作业有很多坑。让用户停留在页面上、使用 AJAX 请求以及在页面内容交付后运行部分脚本的替代方法也存在问题。

我的解决方案是在脚本开头运行 callignore_user_abort(true) ,并在生成内容后运行 callignore_user_abort(true) ,以达到良好的效果,然后运行新闻通讯脚本。或者,使用 AJAX 执行此操作。

首先,有人认为这种方法有问题吗?

其次,如果我使用没有设置时间限制的脚本,并使用 while 循环遍历每封电子邮件,那么如果我一次性执行此操作,内存使用情况会怎样?由于我会覆盖变量,而不是使用新变量,所以我认为它会很低。

第三,因为如果我要发送大量电子邮件,例如每次运行 1000 封,我不想让我的邮件服务器超载。通过我的 cron 作业,我每 5 分钟运行一次脚本,发送一批 50 封电子邮件。如果我一次性执行此操作,我可以发送 50 封电子邮件,调用 sleep 5 分钟,然后继续发送另外 50 封电子邮件吗?如果是这样,在睡眠期间脚本内存使用情况如何?这是一种有效的方法吗?

我在这里真正想做的是想出一种方法来创建一个时事通讯工具,它不需要设置 Cron 作业的复杂(对于非技术人员)任务(这甚至不是一个选项)共享主机),并且不需要用户在单个页面上保持浏览器打开。

欢迎任何想法建议或反馈。谢谢!

I have a few questions about PHP memory usage. I'm going to run some tests on my own, but getting various advice is quite helpful.

I recently learned about the PHP function ignore_user_abort(), which allows a script to continue running even if a user closes the page. I was thinking about using this for my E-mail Newsletter tool instead of Cron jobs, as configuring Cron jobs has various pitfuls. The alternative approach of making a user stay on the page, using AJAX requests, and running part of the script after the page content has been delivered all have issues as well.

My solution would be to run call ignore_user_abort(true) at the beginning of the script, and at the end after the content has been generated, call flush() for good measure, and then run the newsletter script. Alternatively, do this with an AJAX.

First of all, does anyone see issues with that approach?

Second of all, if I used the script with no time limit set, and a while loop going through each email, what would the memory usage be like if I did it in one go? Since I'd be overwriting variables, not using new ones, I'd think it would be low.

Third, because if I am sending a large volume of emails, say 1000 per run, I don't want to overload my mail server. With my cron job, I run the script every 5 minutes, sending a batch of 50 emails out. If I was doing this in a single pass, could I send out 50 emails, call sleep for say 5 minutes, and then continue for another 50 emails? If so, what is the script memory usage like during the sleep period? Would this be an efficient method?

What I'm really trying to do here is come up with a way to create a newsletter tool that doesn't require the complex (for non-technical folks) task of setting up a Cron job (Which isn't even an option on shared hosts), and doesn't require the user to keep their browser open on a single page.

Any ideas suggestions or feedback is welcome. Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

水染的天色ゝ 2024-10-31 08:01:10

在之前的工作中,我们为 PHP 中的一个关键函数编写了一个守护进程,与您所描述的不完全一样,但足够相似——当然有循环和睡眠。我们对其长期稳定性非常怀疑——特别是在内存管理方面——因此我们对其进行了相当严格的压力测试。结果非常好,代码投入生产并完美运行了数月甚至数年。

注意事项:

  • IIRC、PHP 有一个基于计数器的垃圾
    集电极。这意味着,与
    Java,两个对象互相引用
    即使没有,其他也会留在记忆中
    您的程序可以访问。你需要
    当你
    “放弃”你的物品。
  • 网络服务器
    往往有杀死机制
    长时间运行的脚本。这可能会击败
    你来这里的目的——特别是如果
    服务器的配置不能
    调整。

At a former job we wrote a daemon for a critical function in PHP, not exactly what you describe but similar enough -- certainly with loops and sleeps. We were very doubtful about its long-term stability -- specially in memory management--, so we subjected it to pretty tough stress testing. Results were excellent, and the code was put to production and running flawlessly for months if not years.

Caveats:

  • IIRC, PHP has a counter-based garbage
    collector. This means that, unlike in
    Java, two objects referencing each
    other will stay in memory even if not
    accessible by your program. You need
    to be careful about this when you
    'abandon' your objects.
  • Web servers
    often have mechanisms to kill
    long-running scripts. This may defeat
    your purpose here -- specially if the
    server's configuration can't be
    tuned.
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文