Время ожидания страницы превышает время отправки электронных писем, хотя электронные письма отправляются ⇐ C#

[Anonymous]

Этот вопрос поставил меня в тупик. Возможно, этот вопрос придется перенести в Server Fault, но там есть компонент программирования, поэтому я решил начать с него. Кроме того, наша команда по инфраструктуре искренне верит, что с их стороны все в порядке, но это не всегда ничего значит.

В любом случае, у меня есть простое действие GET-POST-Redirect, которое отправляет два отдельных электронных письма с помощью пакета Postal nuget перед перенаправлением на страницу успеха — довольно простая вещь. Действие является асинхронным, и я использую await email.SendAsync() из Postal API.

Когда форма отправляется, первое электронное письмо мгновенно поступает в мой почтовый ящик, но код зависает в этой строке await email.SendAsync() добрых 15–20 секунд, прежде чем перейти к следующей строке (подтверждено в отладчике). Затем дело доходит до отправки второго письма, которое снова мгновенно приходит ко мне в почтовый ящик, и снова код висит на этой строке, независимо от успешной отправки, секунд 15-20, прежде чем перейти к строке с редиректом. В рабочей среде эта задержка после отправки электронного письма, объединенная для двух электронных писем, приводит к сбросу соединения до того, как можно будет отправить ответ на перенаправление. Конечно, я мог бы просто увеличить таймаут страницы, но на самом деле это не решает проблему, поскольку пользователь все равно получает минутную задержку, прежде чем получит ответ.

Я также пробовал отправлять электронные письма синхронно с помощью просто email.Send(), но происходит то же самое. Я просмотрел исходный код Postal, и хотя он использует некоторые специальные оболочки вокруг SMTPClient для отправки асинхронной электронной почты, практически нет ничего, кроме стандартной старой отправки электронной почты C# с помощью синхронного метода Send.

Он также не привязан к серверу, на котором работает сайт, поскольку я вижу одно и то же поведение как в рабочей среде, так и при локальной отладке (оба подключения к одному и тому же рабочему серверу Exchange, хотя).

Он действует так, как будто ожидает, пока сервер Exchange отправит какой-то «готовый» ответ, но, насколько я знаю о SMTP, это так не работает. Ему следует просто отправить электронное письмо на SMTP-сервер и продолжить работу, полагая, что SMTP-сервер действительно сделает то, что должен.

Буду очень признателен за любые идеи, потому что я даже не уверен, как продолжить отладку на этом этапе. Что еще я мог бы протестировать или попробовать?

ОБНОВЛЕНИЕ

Благодаря предложению @MichaelEvanchik опробовать Wireshark, я смог четко увидеть, что на самом деле существует 30-секундная задержка, вызванная сервером Exchange. Он получает последний бит электронного письма, которое нужно отправить, а затем через 30 секунд наконец отвечает клиенту: «Успешно поставлено в очередь для доставки». Именно в этот момент клиент наконец завершает работу, и выполнение кода возобновляется. Итак, я возвращаю это к инфраструктуре.

ОБНОВЛЕНИЕ №2

Итак, по-видимому, на соединителе была установлена ​​30-секундная задержка, чтобы обеспечить подтверждение того, что электронное письмо действительно было отправлено, а не просто поставлено в очередь для доставки. Лично я считаю, что это в первую очередь противоречит принципу «постановка в очередь на доставку», но, несмотря на это, мне не нужно подтверждение того, что сообщение действительно было отправлено, а только то, что оно было получено сервером Exchange, поэтому инфраструктура устраняет задержку.

Подробнее здесь: https://stackoverflow.com/questions/197 ... s-are-sent