Чрезвычайно большое время отклика при использовании запросов - PullRequest
Новая
       26

Чрезвычайно большое время отклика при использовании запросов

2 голосов
/ 07 июля 2019

Описание

У меня есть экземпляр AWS ec2 (ubuntu 16), который запускает приложение Python. В котором я называю некоторые API Facebook Account Kit, а также API Google Play Store. Все они работают отлично, пока я не перезагружу экземпляр за две недели до этого.

После перезагрузки запросы занимают более 5 минут, что совершенно неприемлемо. Мне нужно вручную установить время ожидания более 10 минут, чтобы запрос был завершен.

Проблема возникает только на одном из моих серверов, я работаю в той же среде на другом сервере, она отлично работает с временем отклика менее секунды.

Временно исправить

Чтобы временно устранить проблему, я использую прокси-сервер для завершения запроса.

  1. API-сервер (сервер с проблемой тайм-аута)
  2. прокси-сервер запускает скрипт Python и возвращает результат
  3. API-сервер (сервер с проблемой тайм-аута) возвращает ответ клиенту

Ситуация

  1. Я пытался использовать curl на сервере API, у него также время отклика меньше 1 секунды.
  2. Я пробовал в среде python, используя requests, и время отклика ужасное, выше 5 минут.
    1. Если я установлю заголовок {'Connection' : 'keep-alive' }, второй запрос будет нормальным.
    2. Я включил ведение журнала, и, похоже, запрос застрял при установлении соединения с пунктом назначения.
  3. Я пытался с API, который я написал, и время отклика также ужасно, выше 5 минут.

Текущий код

Запрос с медленным временем отклика. 

url_get_access_token = "https://graph.accountkit.com/v1.3/access_token?grant_type=authorization_code&code=%s&access_token=AA|%s|%s"
url_get_access_token = url_get_access_token % (token, self.facebook_app_id, self.facebook_account_kit_scert)
response = requests.get(url_get_access_token)
body = response.json()

Прокси-сервер, о котором я упоминал выше, является еще одним экземпляром в той же подсети, но я звоню с DNS-сервера. 

response = requests.get("https://proxyserver.com/somepath", params={})

Поскольку это влияет только на один из серверов, это будет проблемой DNS или конфигурацией AWS? Пожалуйста, помогите, спасибо.

Обновление

В результате синхронизированных завитков кажется, что вызов с iPv6 занимает намного больше времени. 

$ time curl -4 -s https://graph.accountkit.com/v1.3
$ time curl -6 -s https://graph.accountkit.com/v1.3

1064 * ipv4 * 

real    0m0.665s
user    0m0.068s
sys 0m0.020s

ipv6 

real    2m7.180s
user    0m0.008s
sys 0m0.000s

1 Ответ

0 голосов
/ 07 июля 2019

На ум приходят два предмета.

DNS

Отладка с помощью: 

$ cat /etc/resolv.conf

$ time dig aaaa graph.accountkit.com

Возможно, у вас есть несколько серверов имен, и не все они отзывчивы, таким образом, вы страдаете от долгих поисков, поскольку время ожидания для одного из них истекло.

TCP

Отладка с помощью: 

$ time curl -4 -s https://graph.accountkit.com/v1.3
$ time curl -6 -s https://graph.accountkit.com/v1.3

Там будет написано «Неверный токен доступа OAuth 2.0», да, да, все в порядке. Что нас интересует, так это то, сколько времени нужно, чтобы подключиться, отправьте GET и получите веб-документ.

Этот домен предлагает адреса A и AAAA. Если транспорт IPv6 - это тост, это может занять некоторое время для requests.get() для переключения на IPv4.

EDIT

Кто-то сломал ваш транспорт IPv6. Это не приемлемо в современном интернете. Тайм-ауты отброшенных пакетов, вероятно, привели к 127-секундному истекшему времени. Инструменты типа traceroute6 и ping6 могут помочь вам или специалисту сети диагностировать где потеря. Возможно, ACL слишком тугой, отбрасывает пакеты IPv6, которые не должны. Отказ от ICMP был бы особенно плохим. Для правильной работы TCP должны быть доставлены ICMP.

A tcpdump (или Wireshark) трассировка пакетов поможет точно определить, что пошло на юг. Возможно, вы страдаете от PMTUD чернокожего . Посмотрите, отображает ли это какие-либо "слишком большие" отчеты ICMP: 

$ sudo tcpdump -tvvvni eth0 icmp6 and ip6[40+0]==2

Просто смотрю на время исходящего порта 443 ретрансляции TCP пролил бы много света на то, почему вещи терпят неудачу в течение двух минут и затем биты внезапно начинают течь.

...