EDITED: у меня есть проблема в моей системе AWS. На каждые несколько запросов требуется почти 130 секунд. Когда я говорю несколько, я имею в виду от 5 до 25 или около того. Обычно, если вы отменяете медленный запрос и отправляете его снова, он просто быстро отвечает. Я также заметил, что это происходит с ЛЮБЫМ запросом, а не только с конкретными. Серверы и внутренняя часть не выглядят перегруженными. система выглядит следующим образом:
ALB with sticky sessions | 2 Web servers | DB on RDS
Система при использовании curl в большинстве случаев отвечает нормально, но когда это занимает много времени, это результат ответа:
Это время измерения завитков по любому URL-адресу.
time_namelookup: 0.004136
time_connect: 130.117558
time_appconnect: 130.125254
time_pretransfer: 130.125340
time_redirect: 0.000000
time_starttransfer: 130.172553
----------
time_total: 130.172615
Помимо time_connect, запрос в порядке в том смысле, что после этого страница загружается. нормальное время отклика системы составляет менее 0,5 секунды.
Я читал об этом, и в документации указано time_connect, относится к
"time_connect - это трехстороннее рукопожатие TCP с точки зрения клиента. Оно заканчивается сразу после того, как клиент отправляет ACK - он не включает время, необходимое для того, чтобы этот ACK достиг сервера. Он должен быть близок к времени приема-передачи. (RTT) на сервер ... "
Это было взято из Вот.
Добавлено: Сама система - это nginx-Python, работающий на экземплярах ec2 с базой данных MySQL на RDS, и она обслуживает статический контент из s3, и пользователи также могут загружать свои собственные файлы. изнутри сервера (экземпляры nginx-python ec2) на локальном хосте curl всегда FINE, это никогда не занимает ДОЛГОЕ ВРЕМЯ. Это наводит меня на мысль, что это что-то связано с LB и nginx, прослушивающими хосты python.
Добавлено: я также попытался оставить только одну из машин в бэкэнде, и проблема не исчезла.
Я не могу найти ничего значимого в AWS Cloudwatch, журналах приложений или мониторинге БД. Есть идеи о том, что мне следует изучить или как устранить эту проблему?
ИЗМЕНИТЬ 3 благодаря приведенному ниже комментарию:
# curl -v -I -L -k -w "@time.txt" -s "https://my-site.com/url/"
* Trying "
* Trying IP.ONE.from.AWS...
* connect to IP.ONE.from.AWS port 443 failed: Connection timed out
* TCP_NODELAY set
* Connected to my-site.com (IP.TWO.from.AWS) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
IP-ONE-from-AWS и IP-TWO-from-AWS - это IP-адреса из региона AWS, к которому я должен подключиться.
Вы разместили свой балансировщик нагрузки в одной общедоступной подсети и одной частной подсети, что является недопустимой конфигурацией и приведет к поведению, аналогичному тому, что вы наблюдаете, потому что балансировщику назначается по крайней мере один общедоступный IP-адрес для каждой подсети, к которой он подключен. .. но по определению общедоступные IP-адреса не работают, если подсеть не является общедоступной.
Необходимо подключить балансировщики нагрузки с выходом в Интернет только в публичные подсети. Их не нужно присоединять к частным подсетям, где экземпляры, стоящие за ними, (или должны быть) развернуты, или к любой другой частной подсети.
В качестве альтернативы вы, возможно, намеревались разместить балансировщик в двух общедоступных подсетях, но одна из них имеет неправильно настроенную таблицу маршрутов VPC или сетевой ACL, которые имеют такой же чистый эффект и блокируют трафик при подключении к этому IP-адресу.