php mail（）是群发邮件的好选择吗？

问题描述

我正在创建一个系统，其中定期发送数千个电子邮件的列表，我知道PHP中的 mail（）函数相当沉重，特别是如果同时呼叫太多次。

我的系统工作方式大致是我在MySQL中创建的电子邮件队列，并使用 mail（），从表中删除前25个发送。而且我每等级25之间等待2秒。

这对服务器来说太费力了，还是可以推一下呢？
每秒可以说50？或者有更好的方式在不牺牲服务器性能的情况下发送许多电子邮件。

我有一个专用服务器，没有任何 mail（）通话限制。

解决方案

除表演外，还有其他因素要考虑，但简短的答案是：是更好的选择。亚马逊SES和MailChimp是我知道的两个听到积极的反馈。

查看j08691关于性能的答案，但使用 mail（）为此目的包括：

1. 可扩展性（你会打墙，没有SMTP服务器可以最终处理，而您已经在考虑了）




2. 诚信 - 滚动自己的群发邮件时，更有可能被标记为垃圾邮件，特别是使用邮件，因为它使用本地sendmail设计。




3. 成本/收益和投资回报率 - 可靠的大众邮件人员获得正确的竞争优势。在某些时候，您每小时支付一次自己的邮件服务器，当您崩溃，下载黑名单，手工编写电子邮件布局，普通维护等等时，可以支付大量邮件服务器的费用。

总的来说，大问题是你必须自己做所有的工作，你可能被标记为垃圾邮件没有付费的服务，即使PHP能够处理您的网页应用程序的其他任何事情，PHP也不会在数百分钟内发送数百封电子邮件。

$ b个人轶事（不是SES的批注，只是大众邮件）：我们有一个客户端，每个广告系列发送了100k +个电子邮件，每天最少有1-3个广告系列。他们开始抱怨客户在两天之后收到关于每日交易的电子邮件。这不是因为邮件库缓慢（即使这个应用程序避免使用简单的邮件），那是不能确定发送所有每个广告系列的电子邮件在em电子邮件不相关之前。我们把它们切换到SES（在我们的结尾有一些优化，但不是太多），他们可以在一小时内清除一个广告系列。

I am creating a system, where a list of thousands of emails will be sent periodically, I know that the mail() function in PHP is quite heavy, specially if calling it too many times simultaneously.

Roughly the way my system works , is that I create queue of emails in MySQL and send them in batches of 25 using mail(), removing from the table the top 25 sent. And I wait 2 seconds between each set of 25.

Is this too much effort for the server or I can push it a bit further?Lets say 50 per second? Or there is a better way of sending many emails in less time without sacrificing Server performance.

I have a dedicated server without any mail() call limit.

解决方案

There are other factors to consider besides performance, but the short answer is: there are better options. Amazon SES and MailChimp are the two I know about have heard positive feedback on.

Look at j08691's answer regarding the performance, but other issues with using mail() for this purpose include:

1. Scalability (you will hit a wall that no SMTP server can handle eventually, and you're already thinking about it)

2. Integrity - You are much more likely to get flagged as spammy when rolling your own mass mailer, especially using mail as it uses the local sendmail by design.

3. Cost/Benefit and ROI - the reliable mass-mailers get it right and for a competitive rate. At some point you are paying yourself less per hour to maintain your mail server when it crashes, getting off of black lists, writing the email layout by hand, general upkeep, etc etc than you would paying for the mass mailer service.

Overall, the big issue is that you have to do all the work yourself and you're likely to get flagged as SPAM for the benefit of not paying for a service that will be able to send hundreds of emails a second versus a hundred a minute when PHP isn't busy doing everything else it handles for your web app.

Personal anecdote (not an endorsement for SES, just mass-mailers) : We had a client that sent 100k+ emails per campaign, with 1 - 3 campaigns per day minimum. They started complaining that the clients were getting emails about "daily deals" 2 days late. It wasn't because the Mailer library was slow (even this app avoided using plain mail), it was that it couldn't be sure to send all of the emails for every campaign before the email was irrelevant. We switched them over to SES (with some optimizing on our end, but not much), and they could clear a campaign in under an hour.

这篇关于php mail（）是群发邮件的好选择吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！