요금 기반 가상 대기실을 사용하는 이유는 무엇인가요?

웹 서버가 처리할 수 있는 동시 사용자 수는 몇 명인가요?

웹 서버가 처리하는 동시 사용자 수와 트랜잭션 흐름의 첫 페이지부터 주문 확인 페이지까지 평균 트랜잭션 시간 또는 방문 기간을 알고 있다면 다음과 같이 리틀의 법칙을 사용하여 이를 사용자 수를 기간으로 나누어 대기열 비율로 변환할 수 있습니다:

대기열 비율 = 동시 사용자 수 / 트랜잭션 시간

요금 기반 대기열 시스템은 얼마나 정확하나요?

Queue-Fair는 사용자가 지정한 비율로 웹사이트 방문자를 전달합니다. 업계에서 가장 정확한 대기열 AI를 통해 1분마다 원하는 방문자 수를 보장하고, 차례가 불렸을 때 참석하지 않은 사람이나 늦게 돌아오는 사람을 자동으로 고려합니다.

이것이 동시 사용자 수로 어떻게 해석될까요? 물론 사이트에 접속하는 모든 방문자가 거래를 완료하는 데 정확한 평균 거래 시간이 걸리지는 않지만, 큰 수의 법칙으로 인해 Queue-Fair를 사용하면 매우 안정적인 동시 사용자 수를 확보할 수 있습니다.

예를 들어 분당 방문자 대기열 비율이 100명이라고 가정해 보겠습니다. 당사는 매분마다 100명의 방문자를 꾸준히 사이트로 보내드리며, 이는 당사가 하는 일이고 놀라울 정도로 잘하는 일입니다. 또한 사람들이 평균(평균) 5분 동안 웹사이트를 이용하고, 그 중 70%가 대기열을 통과한 순간부터 마지막 페이지 요청(거래 완료 여부)을 하는 순간까지 4~6분 정도 걸린다고 가정해 보겠습니다. 이는 평균의 양쪽 표준편차 1분입니다. 통계적으로 말하자면, 5분 30초가 걸리는 방문자 한 명당 4분 30초가 걸리는 방문자가 있다는 뜻이며, 여러 세션에 걸친 개별 방문 시간의 이러한 차이는 어떤 방식으로든 많은 방문자를 계산할 때 서로 상쇄되는 경향이 있습니다. 큰 수의 법칙에 따르면 이러한 상쇄 현상은 참여 인원이 많을수록 점점 더 정확해집니다.

정확히 얼마나 정확한가요? 약간의 통계를 통해 이 문제를 해결할 수 있습니다. 여기에는 5 * 100 = 500이라는 큰 숫자의 표본 크기가 있습니다. 즉, 얼마나 많은 사람들을 조사하고 있는지 알 수 있습니다. 즉, 평균 표준 오차에 대한 통계 공식에 따라 거래 시간에 대한 평균 표준 오차는 1(표준 편차, 1분)을 표본 크기의 제곱근(즉, 500의 제곱근)으로 나누면 거래 시간에 대한 평균 표준 오차는 0.044분 또는 2.7초에 불과하며 이는 1% 미만이라는 것을 의미합니다.

즉, 대기열 비율이 100이고 개별 방문자당 트랜잭션 시간이 5분 내외인 경우 사이트의 동시 사용자 수는 70% 정도인 495~505명으로 예상되므로 비율 기반 대기열을 사용하면 원하는 대로 웹 서버에 매우 안정적인 부하를 제공할 수 있다는 계산이 나옵니다.

하지만 수학이 정확할까요? 예를 들어, 우리가 즐겁게 제곱근을 구하는 표본 크기가 동시 사용자 수를 계산할 때마다(즉, 특정 시점에) 항상 정확히 500이 되는 것은 아니며, 정규(가우스) 분포를 사용하면 실제로는 발생하지 않는 음의 거래 시간이 나올 수도 있습니다. 따라서 방문자 단위, 초 단위 시뮬레이터를 사용하여 이러한 종류의 계산을 확인하기 위해 측정한 결과, 위의 수치를 사용하면 70%의 경우 493~507명의 방문자를 예상해야 한다는 것을 알 수 있으므로 수학이 상당히 잘 맞습니다! 또한 데이터를 측정하면 사이트의 동시 사용자 수가 최소 95% 이상 500 ± 15명임을 알 수 있습니다.

이는 웹 서버가 사이트를 사용하는 사람들의 수를 측정할 수 있는 정확도보다 더 안정적일 것입니다! 더 좋은 점은 방문자의 평균 트랜잭션 시간이나 표준 편차를 모르더라도 이러한 수학적 수치는 알고 있든 모르든 존재하며, 어쨌든 안정적인 부하를 얻을 수 있다는 것입니다.

결론은 Queue-Fair가 원하는 분당 방문자 수를 거의 완벽하게 정확하게 제공하므로 사이트의 동시 사용자 수가 매우 안정 적이며, 사용자가 완전히 제어할 수 있는 안정적인 웹 서버 부하를 제공합니다.

만세!

그리고 이제 경고입니다. 사이트의 동시 사용자 수와 서버 부하의 안정성은 가상 대기실 제공업체가 매분 원하는 방문자 수를 얼마나 정확하게 전송하는지에 따라 크게 달라지므로 가상 대기실 플랫폼을 선택할 때 이 점이 핵심 요소라는 점에 유의할 필요가 있습니다. 당사는 세계에서 가장 정확한 가상 대기실을 제공하기 때문에 서버의 과부하를 가장 잘 막아주는 업체는 Queue-Fair뿐입니다.

대기열 비율을 쉽게 계산하는 방법

서버가 처리할 수 있는 동시 사용자 수 또는 트랜잭션 시간을 모른다면 어떻게 해야 하나요? 병목 현상이 발생할 가능성이 높은 페이지(일반적으로 '지금 구매' 버튼을 클릭한 결과 페이지)를 살펴볼 수 있습니다. Google 애널리틱스를 사용하여 해당 페이지의 월간 순 방문자 수를 찾거나 월간 주문 수를 계산합니다. 이를 30 * 24 * 60 = 43,200으로 나누면 대략 한 달에 걸리는 시간(분)입니다. 이는 한 달 동안의 분당 평균 방문자 수입니다. 여기에 3을 곱합니다. 이는 업무 시간 동안의 분당 평균 방문자 수(대략)입니다. 이를 두 배로 늘립니다. 이 수치가 대기열 비율에 사용하기에 안전한 수치일 것입니다.

예를 들어 한 달에 100,000건의 주문을 처리한다고 가정하면 '지금 구매' 버튼을 100,000번 클릭하는 것입니다. 100,000 / 43,200 = 분당 2.31건의 주문입니다. 이러한 주문의 대부분은 낮에 발생하고 밤에는 서버가 한산할 것으로 예상되므로 여기에 3을 곱하면 업무 시간 동안 서버가 얼마나 바쁜지 대략적으로 추정할 수 있는 분당 7건의 주문이 됩니다. 결과 수치가 50 미만인 경우: 수요에 최고점과 최저점이 있으므로 피크 시간대에 서버가 눈에 띄게 느려지지 않는다면 여기에 2를 곱하여 분당 14명의 활성 사용자를 계산합니다. 수치가 50을 초과하는 경우: 분 단위의 최고점과 최저점은 상대적으로 작아지므로 이 수치를 두 배로 늘리는 것은 안전하지 않습니다. 이 수치는 대기열 비율을 시작하기에 안전한 수치이며 안전하게 관리할 수 있는 초당 요청 수에 해당하며, 시스템이 해당 비율로도 최종 사용자 성능에 대응할 수 있다고 판단되면 언제든지 이 수치를 늘릴 수 있습니다.

주문에 타임스탬프가 있는 경우 최근 한 달 동안 1분 동안 받은 최대 주문을 확인할 수도 있지만, 서버 속도 저하로 인해 이 1분 동안 얼마나 많은 주문이 감소했는지 알 수 없으므로 주의해서 사용하세요.

이 글의 나머지 부분에서는 대기열 비율을 계산하는 몇 가지 다른 방법에 대해 설명합니다.

Gotcha #1: 동시 사용자 수 대 동시 요청 수 대 동시 연결 수 대 동시 세션 수

일반적으로 사용되는 '동시 사용자'에 대한 정의는 두 가지 이상이라는 점에 유의할 필요가 있습니다.

저희는 ' 한 번에 트랜잭션 흐름에 참여하는 사람의 수 '라는 정의를 사용합니다. 대기열 비율을 설정하기 위해 알아야 할 핵심 숫자입니다. 현재 얼마나 많은 사용자가 사이트를 보고 있는지 알 수 있습니다. 동시 세션 수는 일반적으로 동시 연결 수나 동시 사용자 수보다 다소 많은데, 이는 일부 세션이 시간 초과 중이므로 평균 세션 시간이 길어지기 때문입니다.

이를 웹 서버가 한 번에 처리하는 HTTP 요청의 수 인 동시 요청 수와 대조해 보세요. 많은 기술자들이 동시 사용자 수를 말할 때 동시 요청 수를 의미하기 때문에 매우 혼란스러울 수 있습니다.

그런 다음 동시 연결(또는 네트워크 인터페이스 카드의 동일한 서버 포트에 대한 동시 TCP 연결)은 서버 포트 또는 백엔드 서비스에서 한 번에 열려 있는 TCP/IP 소켓의 수입니다. 페이지 요청을 할 때 브라우저는 페이지에서 추가 요청이 있거나 사용자가 다른 페이지로 이동할 경우를 대비하여 기본적으로 연결을 열어 둡니다. 이렇게 하면 새 TCP/IP 연결을 열기 위한 초당 요청 횟수가 줄어들어 서버 프로세스가 더 효율적으로 처리됩니다. 이러한 동시 연결에 대한 시간 제한은 브라우저에 따라 60초에서 절대 닫히지 않는 것까지 다양합니다. 일정 시간 동안 활동이 없으면 서버가 자동으로 연결을 닫을 수도 있습니다. Linux 웹서버에서는 다음 명령을 사용하여 동일한 서버 포트에 대한 동시 연결 수를 확인할 수 있습니다:

netstat -aenp | grep ":80 \|:443 " | wc -l

궁금한 점이 있으면 시도해 보세요. 다시 말하지만, 어떤 사람들은 이것을 "동시 사용자"라고 부르기도 하는데, 실제로는 동시 연결을 의미합니다.

실제로 호스팅 제공업체에 웹 서버가 처리하는 최대 동시 사용자 수(최대 트래픽 양)를 알려달라고 요청하면 평균 트랜잭션 시간, 트랜잭션 흐름의 페이지 수 또는 웹 서버가 처리하는 동시 사용자 수를 알려줄 수 있는 기타 정보를 모른다는 단순한 이유로 동시 세션, 동시 요청 또는 동시 연결에 대한 수치를 알려줄 것입니다. 이러한 숫자는 모두 다른 값을 갖습니다.

호스팅 제공업체나 기술팀에 최대 트래픽 수준에 대한 정보를 요청하는 경우 동시 사용자, 동시 세션, 동시 요청 또는 동시 연결을 의미하는 것인지 명확히 하는 것이 매우 중요합니다.

잘못하면 웹 사이트가 다운될 수 있습니다!

그 이유는 다음과 같습니다. 각 페이지는 단일 HTTP 요청이지만 브라우저가 페이지를 표시하는 데 사용하는 웹 애플리케이션에서 가져온 모든 이미지, 스크립트 및 기타 파일도 HTTP 요청입니다.

기술팀으로부터 서버가 500명의 동시 사용자를 지원한다고 들었지만 실제로는 500명의 동시 요청을 의미한다고 가정해 봅시다. 트랜잭션 시간이 5분이므로 위의 공식을 사용하여 사이트에서 분당 100명의 방문자를 지원할 수 있다고 가정합니다.

할 수 있나요? 아니요.

사람들이 트랜잭션 흐름을 진행할 때 실제로는 각 페이지가 로드되는 동안에만 서버에 요청을 하게 됩니다. 이는 서버가 처리할 수 있는 초당 트래픽 양이나 활성 사용자 수에 영향을 미칩니다. 5분의 트랜잭션 시간 중 일반 사용자에게는 몇 초에 불과합니다. 따라서 500개의 동시 요청은 훨씬 더 많은 동시 사용자를 처리할 수 있다는 의미라고 생각할 수 있지만, 이는 잘못된 생각일 수 있습니다. 이제 트래픽 양이나 총 활성 사용자 수로 웹사이트 용량을 이해하는 것이 얼마나 복잡한 일인지 알 수 있을까요?

동시 요청을 동시 사용자로 전환하기

최대 총 동시 요청 수에서 최대 동시 사용자 수를 계산하려면 다음 사항도 알아야 합니다.

1. 트랜잭션 흐름의 페이지 수
2. 흐름의 첫 페이지에서 마지막 페이지까지의 평균 방문자 트랜잭션 시간
3. 각 페이지를 구성하는 평균 요청 수
4. 서버가 단일 HTTP 요청을 처리하는 데 걸리는 평균 시간

1)과 2)는 이미 알고 계실 것입니다. 이 예에서는 6페이지와 5분입니다. 트랜잭션을 수행하는 동안 표시되는 페이지 수를 쉽게 계산할 수 있습니다. 평균 트랜잭션 시간을 모르는 경우 Google 애널리틱스에서 알려주거나 웹 서버 로그를 확인할 수 있습니다.

3) 및 4)의 경우 Firefox 브라우저가 도움이 될 수 있습니다. 사이트의 페이지를 마우스 오른쪽 버튼으로 클릭하고 요소 검사 및 네트워크 탭을 선택합니다. 그런 다음 CTRL-SHIFT-R을 눌러 페이지를 완전히 새로 고칩니다. 목록에서 페이지의 모든 요소에 대한 네트워크 로드 시간을 확인할 수 있습니다. 전송된 열에서 전송 크기를 확인할 수 있는지 확인해야 합니다. 그렇지 않으면 캐시에서 파일이 제공되어 계산이 엉망이 될 수 있기 때문입니다. 일부 스크립트 및 기타 리소스가 사이트가 아닌 다른 서버에서 제공된 것으로 표시될 수 있으므로 왼쪽의 필터 상자에 사이트의 도메인 이름을 입력할 수 있습니다. 기간 열을 보려면 열 헤더를 마우스 오른쪽 버튼으로 클릭하고 팝업 메뉴에서 타이밍 -> 기간을 선택합니다. 화면이 다음과 같이 표시됩니다:

이 페이지의 Firefox 네트워크 탭에 queue-fair.com의 요청 기간 및 횟수가 표시됩니다.

페이지 표시에 사용되는 파일은 여러 사이트에서 가져올 수 있으므로 왼쪽 상단의 필터를 사용하여 내 사이트의 파일만 표시할 수도 있지만 , 다른 사이트의 파일이 페이지 로드 속도 저하 또는 병목 현상의 원인이 아닌 것이 확실한 경우에만 사용할 수 있습니다.

Firefox는 디스플레이 왼쪽 하단에 요청 수를 계산하여 이 한 페이지에 대해서만 36개의 HTTP 요청을 표시합니다.

트랜잭션 흐름의 모든 페이지에 대해 이 작업을 수행해야 합니다. 총계를 세고 페이지 수로 나누어 각 페이지의 평균 HTTP 요청 수(목록의 3번)를 구합니다. 이제 각 HTML 페이지의 하위 요청 수가 웹 서버가 처리할 수 있는 트래픽의 양을 결정하는 핵심 요소인 이유를 알 수 있습니다.

4)의 경우 지속 시간 열을 살펴보고 모든 페이지에 대한 모든 HTTP 요청의 평균을 찾아야 합니다. 확실하지 않은 경우 0.5초라고 가정하세요. 어차피 여기에는 불확실성이 많이 있습니다(아래 참조).

계산하기

몇 가지 수치를 예로 들어보겠습니다. 이미 예제 서버 프로세스 흐름에 6개의 동적 페이지가 있고(1), 평균 트랜잭션 시간은 5분(2)이라고 말씀드렸습니다. 3)의 경우 페이지당 36개의 HTTP 요청이 있고, 각 HTTP 요청에 대한 서버 처리 시간은 4)의 경우 0.5초라고 가정해 봅시다.

이 수치를 사용하면 500개의 동시 요청을 처리할 수 있는 서버는 500 / (0.5초) = 초당 1000개의 HTTP 요청을 처리할 수 있으며, 이는 완전히 최대치인 경우 분당 60,000개의 HTTP 요청을 처리할 수 있습니다.

5분의 트랜잭션 시간 동안 5 * 60,000 = 300,000개의 HTTP 요청을 처리할 수 있습니다. 엄청나게 많죠?

하지만 각 방문자에 대해 각각 평균 36개의 HTTP 요청이 있는 6개의 페이지가 있으므로 6 * 36 = 216개의 요청이 발생합니다.

따라서 이론적으로 300,000 HTTP 요청 용량은 300,000 / 216 = 1,389명의 동시 사용자를 처리할 수 있습니다.

Gotcha #2: 부하가 걸리면 느려지는 웹 서버

잘됐네요! 대기열 비율이 100밖에 안 될 줄 알았는데 1,389/5분 = 분당 방문자 수 278명이므로 대기열 비율이 더 높아질 수 있습니다!

글쎄요, 아마도 아닐 겁니다. 우선, 위의 계산에서 가정한 것처럼 방문자가 정확히 0.5초 간격으로 깔끔하게 요청을 보내지는 않습니다. 더 중요한 것은 사이트가 바쁘지 않을 때 입력 데이터를 측정했다는 것입니다. 가비지 인, 가비지 아웃.

사이트가 사용량이 많으면 서버가 요청을 처리하는 데 시간이 더 오래 걸리며, 다른 사이트에서도 사용량이 많을 때 페이지를 기다리는 시간이 길어지는 것을 경험했을 것입니다. 이렇게 하면 서버가 단일 HTTP 요청을 처리하는 데 걸리는 평균 시간이 증가하여 (4) 최대 처리량이 감소합니다. 따라서 분당 방문자 수 278명을 절반으로 줄이세요. 그런 다음 다시 절반으로 줄이세요. 현실적으로 최대 로드 시 분당 약 70명의 신규 방문자가 발생하게 될 것입니다.

캐싱을 사용하면 방문자의 브라우저가 모든 페이지에 대해 모든 요청을 할 필요가 없으므로 서버에 필요한 리소스가 줄어들고 서버가 처리할 수 있는 분당 신규 방문자 수가 늘어날 수 있습니다. 여러 서버에 부하를 분산하는 부하 분산 장치를 사용하고 동적 페이지 대신 정적 콘텐츠를 제공하면 각 서버에 필요한 리소스가 줄어들기 때문에 서버 처리 속도가 빨라질 수 있습니다.

또한 일부 페이지는 다른 페이지보다 제작 및 제공에 필요한 리소스가 적기 때문에 모든 페이지가 완료되는 데 동일한 시간이 걸리지 않습니다. 데이터베이스 검색, 검색 쿼리 및 업데이트에 가장 오랜 시간이 걸리므로 신용카드 세부 정보가 처리되고 주문이 저장되기를 기다리거나 주문 가능 여부가 확인되기를 기다리면서 사람들이 쌓이는 프로세스 어딘가에 병목 현상이 발생할 수 있습니다. 모든 트랜잭션 흐름에는 가장 느린 단계가 있으므로 항상 어딘가에 병목 현상이 발생하며, 웹 서버가 처리할 수 있는 동시 사용자 수에 대한 질문에는 항상 최대값이 존재하며 여러 가지 제한이 있을 수 있습니다. 이 경우 대기열 비율을 충분히 낮게 설정하여 서버가 프로세스의 가장 느린 단계에서 동시에 충분한 사용자를 처리할 수 있는 CPU 시간 용량을 확보하여 사용자가 한꺼번에 몰리지 않도록 하는 것이 좋습니다. 그렇지 않으면 웹서버가 말 그대로 멈출 수 있습니다.

그럼 어떻게 해야 하나요?

저희의 경험에 따르면, 첫 번째 판매를 시작할 때 모두가 서버의 대용량 트래픽 처리 능력을 과대평가합니다.

여러분.

느리거나 트래픽이 폭주하는 동안 평균 세션 시간과 최종 사용자 성능을 정확하게 파악하는 것은 쉬운 일이 아닙니다. 가장 좋은 방법은 '가짜' 고객이 실제로 주문 프로세스를 진행하면서 실제와 똑같이 로드 테스트를 진행하고, 로드 테스트 시 실제와 동일한 순서로 동일한 HTTP 요청을 하고, 페이지 간에 동일한 대기 시간을 두고, 가상 방문자 수를 늘리면서 프로세서 부하, IO 처리량 및 응답 시간을 주시하면서 적절한 로드 테스트를 실행하는 것입니다. 이를 위해 Apache JMeter를 사용할 수 있지만(부하가 적거나 속도가 느린 시스템에서는 K6도 좋습니다), 어떤 도구를 사용하든 모든 사용자의 행동을 정확히 모방하는 데는 시간이 많이 걸리고 까다롭습니다(특히 캐싱이 복잡할 경우). 그렇더라도 최대 수치를 절반으로 줄이세요.

그렇지 않은 경우에는 주의해서 사용하세요.

Queue-Fair 포털을 사용하여 언제든지 Queue-Fair 대기열의 대기열 비율을 쉽게 변경할 수 있습니다. 분당 방문자 수 10명 또는 평상시의 거래 속도에서 시작하여 티켓이 판매된 후 잠시 동안 어떻게 진행되는지 살펴본 다음, 프로세서 부하가 낮고 SQL 데이터베이스가 정상이며 무엇보다도 페이지가 응답하는 경우 CTRL-SHIFT-R을 누르면 20% 이하로 올린 후 잠시 기다렸다가 반복하세요. 이 '로드 밸런싱' 중에 필요한 실제 속도를 곧 찾을 수 있을 것이며(우리가 한 일을 보셨나요?), 고객 경험 관점에서 보면 대기열에 있는 고객의 예상 대기 시간이 줄어들고 예상 대기 시간이 짧아지는 응답 시간을 보고 모두가 만족하기 때문에 대기열 속도를 높이는 것이 좋습니다.

대기열 비율을 너무 높게 설정했다가 낮춰야 하는 상황에 처하는 것은 피해야 하는데, 이는 1) 사이트를 사용하는 사람들이 느린 페이지 로딩을 경험하고 2) 예상 대기 시간이 증가한다는 것을 의미하기 때문입니다. 대기열에 있는 모든 사람들이 한숨을 쉬게 될 것입니다!

Gotcha #3: 대기열이 열린 후 너무 빨리 속도를 높이는 경우

주문 프로세스의 어딘가에 병목 현상이 발생할 수 있으며, 모든 거래에는 가장 느린 단계가 있기 때문에 여러 세션이 쌓이게 됩니다. 티켓 판매를 시작한 지 얼마 되지 않아 서버 프로세서 부하가 최대치에 훨씬 못 미치는 것을 확인하고 속도를 높이는 것은 원치 않는 일입니다. 방문자가 '지금 구매' 버튼까지 도달하지 않았을 수도 있습니다. SQL 데이터베이스에서 대기열 비율과 같거나 비슷한 비율로 새 주문이 보고될 때까지 기다린 다음 측정 및 응답성 테스트를 수행합니다. 속도를 높일 때마다 추가 방문자가 병목 현상에 도달하는 데 동일한 시간이 걸리므로 해당 시간이 경과할 때까지는 새로운 속도에서 서버의 성능을 정확하게 평가할 수 없다는 점을 기억하세요.

Gotcha #4: 서버 스냅

대기열이 열리면 대기열 비율을 점진적으로 높이는 것이 가장 좋은 방법에 대해 이미 설명했습니다. 서버에 시스템 충돌 없이 초과할 수 없는 한계가 있다는 것을 알고 있고 그 한계가 무엇인지 알고 있을 수도 있지만, 부하가 이 한계에 가까워질 때 보통 몇 가지 오류나 경고 또는 프로세서 부하가 80%를 초과하는 등 별다른 징후가 없다는 것을 모를 수도 있습니다.

웹 서비스에 장애가 발생하면 매우 빠르게 '스냅'되거나 멈추는 경향이 있습니다. 이는 일반적으로 시스템이 더 이상 요청이 들어오는 대로 빠르게 처리할 수 없게 되면 내부 처리 대기열이 쌓이기 때문입니다. 그러면 시스템은 요청뿐만 아니라 내부 대기열을 처리, 관리, 저장하는 작업을 수행해야 하며, 이 때문에 서버가 한계에 다다르게 됩니다. 아주 빠르게요. 이러한 상황이 발생하면 서버가 잠시 동안 오류 페이지로 응답할 수 있지만, 이를 본 방문자가 즉시 새로 고침을 눌러 부하가 가중되므로 도움이 되지 않습니다.

그 전이라도 방문자가 페이지를 보는 데 약 1초 이상 걸리면 새로 고침을 누릅니다. 방문자가 새로 고침을 누르면 웹서버는 방문자가 더 이상 원본 요청에 대한 응답을 기다리지 않는다는 사실을 알지 못합니다. 원본 요청과 새로 고침 요청이 모두 수신되면 웹서버는 두 요청을 모두 처리합니다. 즉, 웹서버의 업무가 늘어나고 모든 방문자의 응답 속도가 느려지며 새로 고침을 누르는 사람이 많아져 웹서버가 오류 응답을 보내기도 전에 중단되는 악순환이 반복됩니다.

따라서 서버를 필요 이상으로 무리하게 사용하지 마세요. CPU 시간 용량의 마지막 20%를 사용하는 것은 일반적으로 위험을 감수할 가치가 없습니다. Queue-Fair 포털에 표시되는 대기열 크기(차트의 노란색 대기 그림과 선)가 분 단위로 감소하거나 더 느리게 증가하고 있고 표시된 대기 시간이 50분 이하인 경우, 주문을 충분히 빠르게 처리하고 있으며 결국 대기열이 비워지고 대기열 페이지 표시가 자동으로 중지되므로 사용자가 아무것도 할 필요도 없고 상사에게 너무 세게 밀어 부쳐서 깨졌다고 말할 필요도 없습니다. 대기열 앞쪽의 속도가 분당 참가 수(두 가지 모두 Queue-Fair 포털에 표시됨)보다 빠르면 결국에는 도달하게 되며, 전환점은 일반적으로 각 이벤트가 시작되고 최소 몇 분 후입니다. 한정 수량 제품을 판매하는 경우 전환 시점에 도달하기 전에 매진될 가능성이 높습니다.

좋은 소식은 실수로 대기열 비율을 너무 높게 설정하여 서버가 멈춘 경우 서버가 방문자를 다시 처리할 준비가 될 때까지 대기열을 보류 모드로 설정하면 빠르게 복구할 수 있다는 것입니다. 대기 모드에서는 대기열에 있는 사람들에게 온라인 이벤트 전에 디자인할 수 있는 특별한 대기 페이지가 표시됩니다. 대기열이 대기 중일 때는 대기열 앞쪽에서는 아무도 통과할 수 없지만, 새로운 인터넷 방문자는 대기열 뒤쪽에서 대기열에 합류하여 차단이 해제되면 공정하게 대기할 수 있으며, 이는 Queue-Fair가 사이트를 수요로부터 보호하므로 매우 빠르게 이루어집니다. 대기 페이지를 업데이트하여 방문자에게 대기열이 다시 열릴 것으로 예상되는 시간을 알려주면 대기열 비율을 매우 낮게 설정할 수 있는 우수한 사용자 환경을 제공하며, 이미 수십만 명이 대기열에 있는 경우에도 포털 페이지 편집기를 사용하여 쉽게 수행할 수 있습니다. 대기 모드에서는 시스템이 스냅에서 복구되는 동안 필요한 경우 Queue-Fair의 고유한 Admit One 버튼으로 한 번에 한 명씩 통과시킬 수도 있습니다.

따라서 이벤트 진행 중에 서버를 잠시 쉬어야 하는 경우 보류 페이지를 사용하면 서버를 더 빠르게 복구하여 부팅할 수 있습니다.

결론

이 글에서는 비율 기반 대기열이 항상 필요한 이유와 필요한 비율을 계산하는 두 가지 방법을 설명했지만, 전체 트랜잭션 흐름에 대해 완전하고 정확한 가상 방문자 부하 테스트를 수행하지 않았고 이에 대해 매우 확신하지 않는 한 조언은 항상 동일합니다:

1. 대기열 비율을 10으로 설정하거나 일반적인 날의 거래 비율로 시작하세요.
2. 프로세서 로드 및 기타 성능 지표를 확인하세요.
3. 새 주문이 대기열 비율과 같거나 비슷한 비율로 SQL 데이터베이스에 기록될 때까지 기다리세요.
4. 페이지에서 CTRL-SHIFT-R을 눌러 응답성을 확인합니다.
5. 대기열 비율을 20% 이하로 늘립니다.
6. 2단계로 돌아가서 다시 기다립니다.
7. 대기열 크기가 매분 감소하거나 꾸준히 덜 빠르게 증가하고 있고 표시된 대기 시간이 50분 미만이면 더 이상 빠르게 진행할 필요가 없습니다.
8. 편안히 앉아 휴식을 취하세요! Queue-Fair가 도와드리겠습니다.

한정 수량 제품을 판매하는 경우에는 7단계에 신경 쓸 필요가 없습니다.

이는 시스템이 지원할 수 있는 실제 최대 대기열 비율을 모르는 첫 번째 대기열에 대한 것입니다. 이후 대기열의 경우 시스템이 실제로 처리할 수 있는 대기열 비율을 측정한 후에는 동일한 수치를 다시 사용할 수 있지만, 시스템에 변경 사항이 없는 경우에만 가능합니다. 실제로는 시스템이 계속 개발 및 수정 중일 수 있으며 최근 변경 사항이 최대 대기열 비율에 어떤 영향을 미쳤는지 모를 수 있으므로 이전 측정 수치의 절반에서 시작하여 위의 과정을 반복하는 것은 어떨까요?

이것이 바로 Queue-Fair를 사용하여 온세일을 멋지고 안전하게 만드는 방법이며, 항상 후회하는 것보다 안전한 것이 낫다는 것을 기억하세요.