Для разработки мы настроили AWS ALB с одним ec2 на первом AZ. Мы не определили цель для второго AZ. липкие сессии включены.
хром
"timings": {
"blocked": 3.9899999922234564,
"dns": 20.664,
"ssl": 35.21700000000055,
"connect": 21092.345,
"send": 0.1349999999983993,
"wait": 75.01600001432962,
"receive": 0.9250000002793968,
"_blocked_queueing": 2.8999999922234565
},
Firefox
"timings": {
"blocked": 21364,
"dns": 0,
"connect": 21033,
"ssl": 268,
"send": 0,
"wait": 44,
"receive": 0
},
Мы замечаем, что на некоторых страницах первой загрузки мы видим начальное время соединения 21.05 - 21.10 секунд. Это число удивительно постоянное. В остальное время ответ почти мгновенный, как и ожидалось.
Когда мы смотрим на облачные журналы, они сообщают о target_processing_time
из 0.019
для события. Таким образом, кажется, что первоначальное рукопожатие является причиной проблемы.
ЕСТЬ это 21.xx секунды из-за наличия только одной цели в одном азе. ALB, кажется, не интуитивно пытается использовать второй AZ, если у него нет здоровых целей.
Есть ли способ настроить ALB таким образом, чтобы эти 21.xx секунды не возникали каждый раз, когда вызывается загрузка новой страницы?