Нещодавно, коли я користувався браузером для доступу до цього сайту, я намагався оновити його ще кілька разів, і він отримував помилку 503, як показано на рисунку нижче:
Маршрут 503 тимчасово недоступний Тим часом заголовок відповіді виглядає так:
content-length: 608
content-type: text/html
date: Sat, 07 Jan 2023 13:50:32 GMT
via: HTTP/2.0 SLB.205 Тимчасово недоступна помилка сервісу 503
503 — це HTTP-код статусу через тимчасовеОбслуговування сервера абоПеревантаження, сервер наразі не може обробити запит. Цей стан тимчасовий і буде відновлений з часом.
Загалом, помилка 503 здебільшого пов'язана зВисокий трафік на сайтах, що призводить до помилки, спричиненої надмірним трафіком або великою кількістю одночасних ресурсів.
через заголовок відповіді
Ми бачимо це у відповіді 503via: HTTP/2.0 SLB.205Інформація про заголовок відповіді, що стосується заголовка відповіді via, пояснюється наступним чином:
Через
Вказує, який проксі-сервер надає відповідь від клієнта до OCS або навпаки, а також за яким протоколом (і версією) вони надіслали запит.
Коли наступний проксі-сервер отримує запит від першого проксі-сервера, він копіює заголовок Via запиту попереднього проксі-сервера у свій власний запит і додає відповідну інформацію на задню частину, і так далі, коли OCS отримує запит від останнього проксі-сервера, перевіряє заголовок Via, щоб дізнатися маршрут, яким проходить запит. Наприклад: Via:1.0 236-81.D07071953.sina.com.cn:80 (кальмар/2.6.STABLE13) За описом можна приблизно припустити, що цеСервіс SLB (балансування навантаження) безпосередньо повертав помилку 503Тобто запит не потрапив на справжній сервер на нашому бекенді, і користувачу безпосередньо відповідав Alibaba Cloud SLB (балансування навантаження).
У цей момент я раптом подумав, що сервіс SLB (балансування навантаження) від Alibaba Cloud має інші характеристики, а різні специфікації також мають різні обмеження на паралельність, візьмемо простий тип I (slb.s1.small) як приклад.Максимальна кількість підключень, підтримуваних цією специфікацією, становить 5000, нових з'єднань (CPS): 3000, а запитів за секунду (QPS): 1000。 Як показано нижче:
Рішення:Оновлення конфігурацій SLB!! Оновлення конфігурацій SLB!! Оновлення конфігурацій SLB!!
Щодо моніторингу SLB (балансування навантаження), видно, що він перевищив ліміт специфікації.
SSL конфігурації SLB за замовчуванням увімкне http/2.0, оскільки http2.0 повторно використовує TCP-з'єднання, і після встановлення TCP-з'єднання воно буде завантажено лише на один вузол SLB
Конфігурація slb.s1.small з гарантією продуктивності така: Кількість з'єднань: 5000, CPS: 3000, QPS: 1000
QPS цієї специфікації становить 1000, але QPS одного вузла SLB — 1000/(8-1), сьомий шар — 8 вузлів, а QPS одного вузла — близько 142. http/2.0 розміщується на бекенді для налаштування
Ви можете звернутися до неїhttps://help.aliyun.com/knowledge_detail/55193.htmlпояснення, чому кожне з'єднання не досягає піків пропускної здатності; Це одна й та сама причина Ресурси:
Вхід за гіперпосиланням видно.
Вхід за гіперпосиланням видно.
|