CloudWatch에서 제공하는 ELB 대기 시간 통계가 무엇인지 정확하게 알고 싶습니다.AWS ELB 대기 시간 이해
가 문서에 따르면
는 클라이언트로 전송되기 전에 응답이 ELB에 버퍼링 도착 여부입니까?
또는 :
가벼운 최대 대기 시간 CloudWatch 측정 항목이 ropey 3G 연결에 많은 수의 사용자를 보유하고 있는지 설명하고, 가끔씩 느려지는 앱 서버의 기본 문제를 나타내는 경우를 이해하고 싶습니다. .
AWS 지원에있어서, 상기 ELB (HTTP 리스너로 구성된 경우) 대기 시간 메트릭으로 똑딱 시작됩니다 (요청 헤더에서 와서 확인 도착하고 백엔드로 전송) 프록시 역할로
곧 백엔드가 첫 번째 바이트 응답을 보낼 때까지 헤더가 백엔드로 전송됩니다.
POST (또는 고객이 추가 데이터를 전송할 때 HTTP 메소드)의 경우 고객이 데이터를 업로드하는 경우에도 백엔드가 응답을 보내기위한 완전한 요청을 필요로하므로 대기 시간은 계속 똑딱 거립니다 일단 백엔드가 첫 번째 바이트 응답을 보내면. 따라서 데이터 전송 속도가 느린 클라이언트의 경우 대기 시간은 업로드 시간 + 백엔드가 응답 한 시간을 고려합니다.
ELB가 클라이언트에 응답을 반환하는 데 필요한 시간과 관계없이 서버가 ELB의 관점에서 응답을 생성하는 데 걸린 시간을 측정 한 것으로 보입니다.
다른 응용 프로그램 서버 앞에있는 다른로드 밸런서 HAProxy 앞에서 ELB를 사용하는 내 응용 프로그램 중 하나에서 내 자신의 로그를 검토하여이 결론을 얻었습니다. (이 중복 보일지도 모르지만, 그것은 단지 ELB 또는 유일한 HAProxy 사용을 통해 우리에게 여러 가지 장점을 제공합니다.)
여기 내가 말하는 겁니다 설정의 하나를 포함하여 각 요청에
ELB -->>-- EC2+HAProxy -->>-- EC2+Nginx (multipe instances)
HAProxy 로그 several time metricsTr이라고합니다.
Tr : 서버 응답 시간 (HTTP 모드 전용). TCP 연결이 서버에 설정된 순간과 서버가 전체 응답 헤더를 보낸 순간 사이의 경과 시간입니다. 데이터 전송으로 인한 네트워크 오버 헤드없이 순수하게 요청 처리 시간을 보여줍니다.
이제 HAProxy가 무엇을하는지에 대한 많은 논의가 ELB 및 지연 시간 메트릭과 관련되어 있는지 설명해주십시오.HAProxy는 관련된 다른 타이머의 번호를 기록하더라도
얼마나 프록시, 이 Tr 타이머 깔끔하게에 의해 기록 된 값에 해당하는 내 HAProxy 로그의 단일 타이머 각 요청/응답에 다양한 이벤트를 기다리는 보낸다 ELB에 대한 Cloudwatch의 "대기 시간"측정 기준은 분 단위로 표시되며 밀리 초 또는 2 분의 1을 사용합니다. 다른 측정 항목은 크게 변형되었습니다 ... 따라서이 ELB 측정 항목은 응답 시간 클라이언트에 응답을 다시 전달하는 데 필요할 수있는 추가 시간과 관련이없는 응용 프로그램 서버의 수를 나타냅니다.
ELB의 타이머가 HAProxy가 측정하고있는 것과 매우 유사한 것을 측정하지 않는 한, HAProxy와 ELB는 일관되게 일치하지 않을 것입니다. 말 그대로 똑같은 요청으로 동일한 앱 서버의 성능을 측정합니다.
응용 프로그램 서버가 자체 성능 벤치 마크를 수행하지 않고 자체 성능 타이머를 기록하는 경우 지연 시간 메트릭에 대한 높은 값 ()은 응용 프로그램이 클라이언트 연결 품질과 관련이없는 응답 문제가있을 수 있습니다.
이 답변을 주셔서 감사합니다. 한 번 전체 게시 본문이 수신되면 클라이언트가 처리량에 대해 신경 쓰지 않으면 서 백엔드의 대기 시간 성능을 측정하는 방법에 대한 생각을 갖고 있습니까? –