Мы пытаемся диагностировать случайную проблему, которая возникает в приложении, вызывающем SNS, что приводит к тайм-аутам приложения.
Мы создали тестовый пример, который помещает 1 000 000 сообщений в SNS. Большинство сообщений go проходят менее чем за 2 секунды, но иногда (где-то между 1 на 30 000 и 1 на 100 000) сообщение занимает чуть более 60 секунд - это слишком медленно для моего варианта использования.
Мы обнаружили, что Boto 3 имеет логи повторных попыток c, которые по умолчанию будут ожидать 60 секунд, а затем повторять запрос - это поведение, которое я наблюдаю для этого небольшого процента запросов при первой успешной попытке повторения.
Это тест:
import boto3
session = boto3.Session(profile_name='my-profile', region_name='ap-southeast-2')
sns = session.client("sns")
topic_arn = "arn:aws:sns:ap-southeast-2:123456789012:my-sns-topic"
for x in range(0, 1000000):
response = sns.publish(Message="Test", TopicArn=topic_arn)
Пытаясь выяснить, почему первый запрос не прошел, мы запустили трассировку WireShark, чтобы получить больше информации, и нашли некоторые интересные результаты.
Большинство запросов к SNS инициируются с Client Hello, используя TLSv1.2 , и быстро отвечают ACK, а затем Server Hello.
Запросы, время ожидания / сбоя которых инициируется с Client Hello с использованием TLSv1 . На этот вопрос отвечает ACK, но нет Server Hello - через 60 секунд мы видим FIN, ACK от клиента.
Мы подтвердили, что когда мы видим, что TLSv1 используется только для ~ 0,001% Client Hello запросов, и что всякий раз, когда используется TLSv1, время ожидания истекает.
Почему Boto 3 иногда использует TLSv1 для инициирования соединения? Это что-то внутри Boto 3 (boto3 1.11.15, botocore 1.14.15), Python (3.6.8), Операционная система (Amazon Linux 4.14.154-99.181) или где-либо еще? Что мы можем сделать для дальнейшей диагностики и исправления поведения?
К сожалению, корректировка пороговых значений политики повторных попыток не является допустимым решением для этого варианта использования.