Наскоро, когато използвах браузър, за да достъпя този сайт, опитах да го обновя още няколко пъти и получаваше грешка 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Информацията за заглавието на отговора, отнасяща се до заглавието на отговора виа, се обяснява по следния начин:
През
Показва кой прокси сървърира отговора от клиента към OCS или обратно, и с кой протокол (и версия) са изпратили заявката.
Когато следващият прокси сървър получи заявката от първия прокси сървър, той ще копира Via заглавието на заявката на предишния прокси сървър в своя собствена заявка и ще добави съответната си информация в задната част, и така нататък, когато OCS получи заявката от последния прокси сървър, проверява Via хедъра, за да знае маршрута, по който преминава заявката. Например: Via:1.0 236-81.D07071953.sina.com.cn:80 (калмар/2.6.STABLE13) Въз основа на описанието можем приблизително да предположим, че е такаSLB (load balancing) услугата върна директно грешка 503Тоест, заявката не достигна до реалния сървър в нашия бекенд, а заявката беше директно отговорена от Alibaba Cloud SLB (Load Balancing) на потребителя.
В този момент изведнъж си помислих, че услугата SLB (load balancing) на 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обяснение защо всяка връзка не достига пикове на пропускателната способност; Двете са една и съща причина Ресурси:
Входът към хиперлинк е видим.
Входът към хиперлинк е видим.
|