2014-12-26 3 views
3

우리는 HAProxy - 클라이언트 요청을 매우 빠르게받는 데 시간이 걸리는 이유는 무엇입니까?

  1. 라우팅 트래픽을 요청 우리의 서버에
  2. SSL 종료

ulimit를의 하위 도메인에 따라 두 작업

을 수행하는 haproxy 아마존 EC2에 (V 1.5.1) 설치를 동시 연결은 ~ 3000입니다.

설정 파일은 다음과 같습니다. 우리가 직면하고있는 문제는 haproxy 로그에서 Tq 시간이 매우 (2-3 초) 높다는 것입니다. 구성에 문제가 있거나 뭔가 빠졌습니까?

global 
    daemon 
    maxconn 64000 
    tune.ssl.default-dh-param 2048 
    log 127.0.0.1 local0 debug 

defaults 
    mode http 
    option abortonclose 
    option forwardfor 
    option http-server-close 
    option httplog 
    timeout connect 9s 
    timeout client 60s 
    timeout server 30s 
    stats enable 
    stats uri /stats 
    stats realm Haproxy\ Statistics 
    stats auth username:nopass 

frontend www-http 
    bind *:80 

    maxconn 64000 
    http-request set-header U-Request-Source %[src] 
    reqadd X-Forwarded-Proto:\ http 

    errorfile 503 /var/www/html/sorry.html 

    acl host_A hdr_dom(host) -f /etc/A.lst 
    acl host_B hdr_dom(host) -f /etc/B.lst 
    use_backend www-A   if host_A 
    use_backend www-B   if host_B 
    log global 

frontend www-https 
    bind *:443 ssl crt /etc/ssl/private/my.pem no-sslv3 
    http-request set-header U-Request-Source %[src] 
    maxconn 64000 
    reqadd X-Forwarded-Proto:\ https 

    errorfile 503 /var/www/html/sorry.html 

    acl host_A  hdr_dom(host) -f /etc/A.lst 
    acl host_B  hdr_dom(host) -f /etc/B.lst 

    use_backend www-A if host_A 
    use_backend www-B if host_B 
    log global 


backend www-A 
    redirect scheme https if !{ ssl_fc } 
    server app1 app1.a.mydomain.com:80 check port 80 

backend www-B 
    redirect scheme https if !{ ssl_fc } 
    server app1 app1.b.mydomain.com:80 check port 80 
+0

꾸준히? 때때로? 실적에 문제가 있거나 적극적으로 대응하고 있습니까? –

+0

매우 자주 발생합니다. 350 만 건의 요청 중 70 %는 3 초 이상 걸렸습니다. 그러나 응용 프로그램에서 비례 속도가 느려지지 않습니다. 숫자를 잘못 읽은거야? 일반적인 로그 라인은 다음과 같습니다 :'[27/Dec/2014 : 12 : 44 : 02.438] www-https ~ www-cluster1/app1 4959/0/0/8/4967 200 423' – amdalal

+0

이 HAProxy는 Elastic 로드 밸런서 (ELB) 또는 Cloudfront (또는 이와 유사한 풀 - 스루 CDN)의 출처입니까? –

답변

7

내 첫번째 생각은 HAProxy의 문서에서이 있었다 : 3000에 가까운

Tq 경우, 패킷이 아마 클라이언트와 프록시 사이에 손실되었습니다. 이것은 로컬 네트워크에서는 매우 드물지만 클라이언트가 먼 원격 네트워크에 있고 많은 요청을 보낼 때 발생할 수 있습니다. Tq정말 가까운 3000 밀리 초 때

는 ... 그러나, 일반적으로 만 사실입니다. 나는 대륙 횡단 연결의 로그에서 이것을 보지만, 가끔씩은 아주 드물다. Tq도 시간이 추가 요청을 기다리는 동안 측정 이후 option http-server-close 큰 요청 시간을 표시 할 수 있습니다 설정

대신, 나는 당신이보고있는 것은 이것이다 생각한다.

그럴 가능성이 더 큽니다.

"의심스러운"로그 항목 중 하나를 찾은 다음 위로 스크롤하여 동일한 원본 IP 및 포트에서 이전 항목을 찾을 수 있습니다.

예를 들면, 내 로그에서 :

이러한 요청은 모두 동일한 IP 주소 와 동일한 소스 포트입니다
Dec 28 20:29:00 localhost haproxy[28333]: x.x.x.x:45062 [28/Dec/2014:20:28:58.623] ... 2022/0/0/12/2034 200 18599 ... 

Dec 28 20:29:17 localhost haproxy[28333]: x.x.x.x:45062 [28/Dec/2014:20:29:00.657] ... 17091/0/0/45/17136 200 19599 ... 

- 따라서이 분리 같은 클라이언트 연결에서 두 요청입니다 시간은 ~ 17 초 (이 특정 프록시 클러스터의 기본값보다 keepalives를 길게 허용).

Tq 타이머 (위의 값은 2022ms 및 17091ms)는 "클라이언트 요청을 얻는 총 시간"입니다. - 주어진 클라이언트의 초기 요청에서이 타이머는 헤더의 끝이 디코딩됩니다. 그러나 후속 요청에서이 타이머는 다음 요청이 도착하기 전에 끝 또는 이전 요청 이후에 경과 된 유휴 시간도 포함합니다. (내가 다시 돌아 가면 처음 IP 주소가 도착할 때까지 동일한 IP/포트 쌍에서 더 많은 요청을 발견하게됩니다. 실제로는 항상 023이되지는 않습니다.

로그에서 역 추적을하고 시간이 모두 합쳐진 동일한 클라이언트 IP 및 포트에서 이전 요청을 찾을 수 있다면 HAProxy는 열린 상태의 연결 유지에 소요 된 시간을 계산합니다. 클라이언트로부터 다음 요청을 기다리는 중 ...그래서이 행동은 아주 정상적이며 우려의 원인이되어서는 안됩니다.

option http-server-close을 사용하면 클라이언트 측 연결을 유지하면서 클라이언트 연결을 유지하면서 클라이언트 연결을 유지할 수있는 이점을 제공하여 클라이언트 연결을 유지하면서 (일반적으로) 더 긴 경로를 최적화 할 수 있습니다. 백엔드 서버 리소스를 유휴 연결에 묶지 않음).

http://cbonte.github.io/haproxy-dconv/configuration-1.5.html#8.4

관련 문제