Graph Mail API: 504 ошибки времени ожидания шлюза

Question

У меня есть скрипт, который загружает сообщения из почтового ящика Office 365.В логах скрипта я замечаю множество ответов с этой ошибкой Response: 504, Gateway Timeout.Ошибка возникает несколько раз в неделю в несколько раз.Вот даты последних нескольких событий:

• 12/05/2018 07:51:44 PM
• 12/05/2018 05:50:58 PM
• 12/05/2018 03:50:54
• 12/05/2018 03:51:01
• 12/04/2018 17:53:13
• 11/28/2018 03:50:53
• 11/22/2018 11:50:53

В остальное время скрипт работает отличнобез ошибок.Документация гласит, что этот код ошибки указывает на то, что:

"Сервер, действуя в качестве прокси-сервера, не получил своевременный ответ от вышестоящего сервера, к которому он должен был получить доступпопытка выполнить запрос. Может произойти вместе с 503. "

Я видел несколько других сообщений по этому поводу, но ни один из них действительно не предлагал объяснение того, почему возникает эта ошибка, или что может бытьсделано, чтобы избежать этого.Если время ответа сервера истекло, значит ли это, что мне нужно изменить свои запросы?Прямо сейчас я запрашиваю сообщения порциями по 1000, используя параметр ответа @odata.nextLink, чтобы запросить следующую порцию.

Answer 1

504, скорее всего, вызвано размером вашей страницы.1000 - это размер страницы огромного размера, и, скорее всего, время запроса истекает при попытке получить столько писем за раз (особенно, если сами письма большие).

Microsoft Graph - это API-аггрегатор, который, под прикрытием, передает каждый входящий запрос одному или нескольким базовым API.В этом случае он передает запрос в API Exchange / Outlook.

При размере страницы 1000 Graph необходимо подождать, пока Exchange создаст ответ с 1000 электронными письмами и передать его обратно в Graph для окончательной обработки (Graph переписывает, фильтрует и объединяет ответы API, чтобы вы моглиполучить последовательную OData обратно, независимо от конечных точек, которые вы ударили).Исключение 504 - Gateway timeout означает, что тайм-аут графика истек до того, как основная рабочая нагрузка сможет вернуть результат.

Использование меньшего размера страницы (довольно типичное значение 100-300) должно гарантировать, что основная рабочая нагрузка может ответить до истечения времени ожидания.Некоторые люди пытались урезать 100 обратно за раз, пока они не были устранены, но я бы не рекомендовал эту методологию, поскольку это неизбежно означает, что вы не решили проблему, а только представили более редкие условия гонки.