Atraso longo de resposta do servidor - 60 a 90 segundos - ao usar o PHP Mail () no IIS7.5

Question

Temos um Windows 2008 Server executando o PHP 5.2.11 no IIS 7.5

Quando qualquer script no servidor chama uma função mail() , ele não apresenta erros e envia o email quase instantaneamente. No entanto, o servidor irá "travar" por cerca de 60 a 90 segundos até começar a enviar as informações de volta ao navegador. Esse atraso parece ser maior se mail() não tiver sido chamado nos 2 minutos anteriores.

Eu vi esse problema na guia "rede" das ferramentas de desenvolvedor do Google Chrome e ele diz "aguardando" por todo esse período. Quando esse atraso terminar, todas as informações serão enviadas corretamente para o navegador e a página será renderizada normalmente.

Porções potencialmente relevantes da phpinfo() output:

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

    

Answer 1

O PHP mail () é bastante ineficiente para começar, o manual do PHP diz:

It is worth noting that the mail() function is not suitable for larger volumes of email in a loop. This function opens and closes an SMTP socket for each email, which is not very efficient.

Não é particularmente relevante quando o número de mensagens é 1, mas há outro potencial de efeito:

The Windows implementation of mail() differs in many ways from the Unix implementation. First, it doesn't use a local binary for composing messages but only operates on direct sockets which means a MTA is needed listening on a network socket (which can either on the localhost or a remote machine).

Assim, ao contrário da versão Unix, ele não pode disparar em um daemon local, ele tem que esperar pela rede.

Eu não sou um programador, mas isso é claramente um problema de codificação. É provável que a função de email esteja esperando uma resposta específica do seu MTA e não a obtenha, 60 segundos parece um valor de tempo limite bastante normal. Além disso, o código de interface do usuário do frontend não deve estar aguardando no mail (), que normalmente é um processo em segundo plano. Não é muito difícil fazer isso de forma assíncrona.

Em resumo, você provavelmente poderia corrigir isso no nível do MTA (talvez configurando um local no servidor IIS), mas é realmente um problema de codificação. Sugira aos seus desenvolvedores que eles não usem mail () quando o desempenho for importante e não bloqueiem o seu código de frontend quando você estiver esperando por ele.