한계 프로브

다른 하네스가 되는가를 본다면, 여기는 어디서 깨지는지를 찾습니다. 축마다 값을 키워 가며 쏘고 경계를 기록합니다.

읽는 법

한 번 실패하면 그 축은 멈춘다 — 더 큰 값은 볼 것도 없고, 계속 쏘면 시간만 버린다. 경계는 「마지막 통과 → 첫 실패」로 적힌다.
전 구간 통과도 결과다 — 스윕 범위 안에서 한계를 못 찾았다는 뜻이고, 그러면 그 축은 당분간 걱정하지 않아도 된다.
실패뿐 아니라 지연의 계단도 신호다 — 동시성 축에서 성공은 하는데 시간이 갑자기 뛰면 풀 상한에 걸려 줄을 서고 있는 것이다.
⚠ 재는 것은 경로 전체다 — 브라우저 → 프록시 → HCG → Azure Relay → HCA → 앱. 어느 구간이 끊었는지는 숫자만으로 알 수 없다. 경계가 나오면 그 다음 질문이 어느 홉인가다.

prism-proxy 의

reverse-proxy.middleware.ts

에 실측 전 추정치가 그대로 남아 있습니다.

“이 숫자들은 실측 전 추정치다. 천장은 자원 하나에 동시 32 소켓” → #6 동시 요청
“https-proxy-agent 가 CONNECT 터널 소켓을 실제로 풀링하는지는 붙여 봐야 안다. 재사용이 안 되면 왕복이 그대로 나므로, 첫 요청과 두 번째 요청의 지연 차이를 먼저 확인할 것” → #1 터널 재사용

브라우저가 보는 주소

https://aws-insider-e1e444fd-dfae-480a-b782-5eaa35682f5e.feelanet.ai

요청 유도

축 6개, 전체 실행에 약 3분. 지연 축(#5)이 가장 오래 걸리므로 급하면 축별로 따로 돌리세요.

축마다 따로 돌릴 수도 있습니다 — 지연 축이 가장 오래 걸립니다.

같은 요청을 연달아 5번 보내 지연을 비교한다. keepAlive 가 실제로 먹으면 첫 요청만 느리고 나머지는 빨라야 한다. 전부 비슷하게 느리면 매번 터널을 새로 여는 것이다.

★ 코드 주석의 '붙여 봐야 안다' 가 이 축이다. 재사용이 안 되면 페이지 한 장이 자산 30~50 요청인 이 앱에서 초 단위로 느려진다.

1MB 부터 키우며 내려받는다. 프록시가 본문을 버퍼링하면 큰 응답에서 메모리가 튀거나 끊긴다 — H-A 의 재작성 경로가 8MB 를 통과시켜야 하는 이유와 같은 축이다.

1MB 부터 키우며 올린다. 업로드는 프록시가 본문을 파싱하지 않아야 통과한다 — prism-proxy 가 프록시 경로에서 bodyParser 를 끈 것이 이 축의 전제다.

커스텀 헤더를 키우며 보낸다. 쿠키가 쌓이거나 토큰이 헤더로 오가는 앱에서 431 이 나는 지점을 찾는다. 서버가 본 헤더 총 바이트도 함께 돌려받아 중간 변조를 확인한다.

앱이 응답을 늦게 주도록 해서 중간 장비의 타임아웃을 찾는다. 오래 도는 API 나 리포트 생성이 있는 앱에서 먼저 터지는 축이다.

가장 오래 걸린다(최대 2분). 급하면 이 축만 빼고 돌려도 된다.

동시에 N개를 쏜다. 프록시의 UPSTREAM_MAX_SOCKETS(32)와 릴레이·HCA 슬롯(리스너당 100)이 실제로 어디서 걸리는지 본다. 실패뿐 아니라 **지연이 계단처럼 뛰는 지점**도 신호다.

★ 코드 주석의 '실측 전 추정치' 가 이 축이다.