以编程方式个性化批量发送电子邮件,不会超时

发布于 2024-07-29 20:46:33 字数 747 浏览 2 评论 0原文

我有一份来自世界各地的大约 5,000 到 10,000 个(个人用户提供的)电子邮件地址的列表,每个地址都与他们的用户名和语言代码相关联。 我还有一条消息被翻译成我想要通过电子邮件发送的用户的不同语言。 现在,我想向每个地址发送一封纯文本电子邮件,电子邮件的实际文本根据用户语言而变化,并使用我发送电子邮件的人的用户名进行个性化设置。

由于个性化要求,并且事实上他们只会通过电子邮件发送一次(每年或两年,具有重叠但不同的用户列表),正式的邮件列表可能(并且最好)已经消失。 第三方批量电子邮件服务也已退出。

忽略编程时间,在(最好是)PHP 中执行此操作最省时间的手动方法是什么? (我正在编写脚本,但不一定是最终“按下按钮”发送脚本的人。)理想的结果是发送者只需键入一个命令即可运行脚本(提供电子邮件列表)并且所有电子邮件都将被发送,无需更多用户干预。 这意味着我希望避免诸如设置 cron 作业来重复运行脚本直到电子邮件列表耗尽之类的事情。

一年前完成此操作时,我编写了一个 PHP 脚本,该脚本只需逐行读取电子邮件列表,处理用户名、电子邮件地址和语言代码,并从中构建所需的电子邮件文本,然后将其提供给 PHPMailer 发送单独。 我遇到的问题是脚本超时,我不知道它到了哪里,以便我可以在正确的位置修剪电子邮件列表以重新开始。 我最终手动将 1 个电子邮件列表分成几个足够短的子列表,以便脚本不会超时。 如何避免超时,或跟踪脚本在电子邮件地址方面的位置,以便可以手动重新启动并且不会向任何人发送多次电子邮件?

还有哪些其他问题需要考虑,例如避免列入黑名单等?

I have a list of around 5,000 to 10,000 (individual user supplied) email addresses from people all over the world, each associated with their username and language codes. I also have a single message translated into the different languages of the users that I want to email. Now, I would like to send a single plain text email to each of the address, with the actual text of the email varying based on the user language, and personalised with the username of the person I'm emailing.

Because of the personalised requirement, and the fact that they will only be emailed once (per year or two with a overlapped but different user list), formal mailing list is probably (& preferably) out. 3rd party bulk email service is also out.

Ignoring programming time, what is the least manually time consuming way to do this in (preferably) PHP? (I am writing the script(s), but not necessarily the person that end up "pressing the button" to send it.) The ideal result is the person sending only having to type a single command to run the script (supplying the email list) and all the email will be sent with no more user intervention. This mean I am looking to avoid things like setting up cron jobs to run the script repeatedly until the email list is exhausted.

When this was done before a year ago, I wrote a PHP script that simply read in the email list line by line processing the username, email address, and language code and build the desired email text out of that before supplying it to PHPMailer to send individually. The problem I had was the script timing out and me not knowing where it got up to so that I can trim the email list at the right place to start again. I ended up manually splitting up the 1 email list into several sub-list that was short enough so that the script doesn't time out. How do I either avoid timing out, or keep track of where the script is up to email address wise so that it can be restarted manually and no person is sent emails more than once?

What other issues are there to take into account, such as avoiding blacklisting etc.?

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

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

发布评论

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

评论(3

痞味浪人 2024-08-05 20:46:33

您需要阅读函数 set_time_limit 以及有关内存的 ini_set('memory_limit', xxMB') ;

您可以从您的 Web 进程运行 php cli 脚本,该脚本会分叉 (pcntl_fork) 然后杀死父进程(父 cli 进程退出)。 然后,运行脚本的网络服务器线程可以继续执行其他代码或退出。

现在,cli 子进程 (A) 可以分叉(并成为父进程)并监视发送电子邮件的子进程 (B)。 如果子进程 B 死亡,现在的父进程 A 可以再次分叉,新的子进程会从前一个进程停止的地方继续。

您必须在文件/db/共享内存中或通过配对套接字(socket_create_pair) 与父进程。

我希望你能明白。

You need to read about the function set_time_limit and maybe ini_set('memory_limit', xxMB') for memory;

You can run a php cli script from your web process, which forks (pcntl_fork) then kills the parent (the parent cli process exits). The webserver thread running the script can then continue with other code or exit.

Now the cli child process (A) can fork (and become the parent) and monitor a child (B) which sends out the emails. If the child B dies, the now parent A process can fork again and the new child continues where the previous left off.

You have to keep track of who you sent email to in a file/db/shared memory or through paired sockets (socket_create_pair) with the parent process.

I hope you get the idea.

红颜悴 2024-08-05 20:46:33

PHP 不是适合这里工作的工具 - 您需要独立于 Web 服务器运行的东西(尽管可能由它触发),否则您肯定会遇到超时。

例如,您可以将 PHP system() 输出到另一个脚本(Perl?Python?),该脚本从数据库中读取作业信息,然后分叉到后台来完成其工作。

PHP's not the right tool for the job here - you'll want something that runs independent of a web server (although potentially triggered by it) or you'll certainly run into timeouts.

For example, you could have PHP system() out to another script (Perl? Python?), which reads job information from a database then forks into the background to do its work.

一场春暖 2024-08-05 20:46:33

您说没有 Cron 脚本 - 您无权访问服务器上的 Cron 吗? 或者您是否不想在每次必须发送邮件作业时手动设置 Cron 作业?

您可能想查看 http://pear.php.net/package/Mail_Queue -这是我最近一直在使用的东西。 您可以让用户调用的脚本将所有电子邮件一次转储到邮件队列中。 这比实际即时发送电子邮件要快得多,因为您不必处理服务器之间的通信,而只需处理数据库。

然后,您有一个 Cron 脚本,每隔几分钟调用 Mail_Queue::sendMailsInQueue 命令,并限制每次 Cron 调用发送的电子邮件数量。 如果您担心的话,您不必弄乱 Cron 脚本 - 如果队列为空,它就会退出。 然后,您的电子邮件将以每次调用的合理速度从服务器中流出。 这将防止由于每个 cron 调用的电子邮件限制而导致超时。 它还将有助于避免其他邮件服务器的麻烦,这些服务器可能会不高兴突然受到来自您的大量电子邮件的打击。

You said no Cron scripts - do you not have access to Cron on your server? Or is your concern not wanting to manually set up the Cron job every time a mail job has to be sent out?

You might want to look at http://pear.php.net/package/Mail_Queue - it's something I've been using recently. You can have your user-called script dump all the emails at once into the mail queue. This is much faster than actually sending the emails on the fly since you won't have to deal with communication between servers, but rather just your database.

Then you have a Cron script that, every few minutes, calls the Mail_Queue::sendMailsInQueue command with a limit on the number of emails it sends per Cron call. You won't have to mess with the Cron script if that's your concern - if the queue is empty, it'll just exit. Your email will then trickle out of the server at a reasonable pace per call. This will prevent timeouts due to the limit on emails per cron call. It will also help avoid trouble with other mail servers, who might not be happy to suddenly be hammered by a lot of emails from you at once.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文