Время ожидания страницы отправляется, даже если письма отправлены

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

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

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

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

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

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

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

ОБНОВИТЬ

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

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

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

1 ответ

Решение

Wireshark может пролить некоторые подсказки. знак равно

Это то, как продолжить отладку, и покажет вам все, что происходит от http-сервера до SMTP.

Другие вопросы по тегам