☰

在 IIS7.5 上使用 PHP Mail() 时，服务器响应延迟较长 - 60 到 90 秒

tag-icon • tag-icon php email iis
在 IIS7.5 上使用 PHP Mail() 时，服务器响应延迟较长 - 60 到 90 秒

我们有一台在 IIS 7.5 上运行 PHP 5.2.11 的 Windows 2008 Server

当服务器上的任何脚本调用mail()函数时，它不会出现任何错误，并且几乎立即发送电子邮件。但是，服务器将“挂起”约 60 到 90 秒，直到它开始将信息发送回浏览器。如果mail()在前 2 分钟内没有被调用，这个延迟似乎会更长。

我在 Chrome 开发者工具的“网络”选项卡中查看了这个问题，它只是显示“等待”整个时间段。一旦延迟结束，所有信息都会正确发送到浏览器，页面就会正常呈现。

输出中可能相关的部分phpinfo()：

Internal Sendmail Support for Windows - enabled
sendmail_from - no value
sendmail_path - no value
SMTP - mail.samedomain.com
smtp_port - 25
mail.force_extra_parameters - no value

答案1

PHP mail() 一开始就效率很低，PHP 手册本身就说：

值得注意的是，mail() 函数不适合循环处理大量电子邮件。此函数会为每封电子邮件打开和关闭一个 SMTP 套接字，效率不高。

当消息数量为 1 时并不特别相关，但还有另一个潜在的陷阱：

Windows 的 mail() 实现与 Unix 实现在很多方面都不同。首先，它不使用本地二进制文件来编写消息，而只在直接套接字上运行，这意味着需要 MTA 监听网络套接字（可以是本地主机，也可以是远程计算机）。

因此与 Unix 版本不同，它无法在本地守护进程处启动，而必须等待网络。

我不是程序员，但这显然是一个编码问题。很可能邮件功能正在等待 MTA 的某个响应，但没有得到响应，60 秒听起来是一个相当标准的超时值。此外，您的前端 UI 代码不应该等待 mail()，这通常是后台进程。异步执行此操作并不太难。

总而言之，您可能可以在 MTA 级别修复此问题（可能通过在 IIS 服务器上设置本地 MTA 来修复），但这实际上是一个编码问题。当性能很重要时，请向您的开发人员建议不要使用 mail()，并且在等待时不要阻止您的前端代码。

相关内容