2012-08-23 2 views
2

"Hello World!"서비스를 제공하는 간단한 꼬인 앱이 있습니다. HTTP 프로토콜을 통해. 모든 프로세서를 사용하기 위해 여러 인스턴스를 실행하려고합니다.haproxy 뒤 꼬인 앱

하지만 단일 꼬인 앱은 haproxy 뒤에 동일한 앱의 1,2,5 번 인스턴스보다 훨씬 많은 요청을 처리한다고 언급했습니다. 나는 이것이 왜 일어나는지를 알 수 없다.

저는 JMeter를 통해 /이되는 5000 개의 스레드를 실행합니다. 127.0.0.1:9001에서 실행하면 500ms 시간마다 각 요청을 성공적으로 처리합니다. 127.0.0.1:8080에서 실행하면 응답 중 일부는 503 Service Unavailable이고 일부는 500ms 이상 실행됩니다. 여기

내 구성 파일입니다

global 
    maxconn 500000 
    user german 

defaults 
    mode http 
    retries 0 
    timeout connect 5000ms 
    timeout client 50000ms 
    timeout server 50000ms 
    balance roundrobin 
    # if something goes wrong with server, redistribute client to a working server 
    option redispatch 

listen http 127.0.0.1:8080 
    mode http 
    option httpchk GET/HTTP/1.1 

    server prototype-local 127.0.0.1:9001 maxconn 0 weight 1 maxqueue 0 cookie server01 check inter 5000 rise 1 fall 3 

    balance roundrobin 

    # to see ip's of clients 
    option forwardfor 
    option http-server-close 
    # disable or enable immediate session resource cleaning(useful for chat) 
    # option nolinger 
    # inserts cookie to each client requet to identify a process 
    cookie SWCOMMET insert indirect nocache 
    # will be enalbed as soon as main server with process crashed :nice fail resistance 
    option allbackups 

답변

0

나는 그것이 500ms로 시간

당신이 농담에서 성공적으로 각각의 요청을 처리 127.0.0.1:9001에서 실행? "안녕하세요 세상"과 같은 간단한 응용 프로그램이 500ms 이내에 응답하면 어딘가에 무언가가 깨졌습니다.

서버가 스왑되지 않는지 (예 : 메모리 누수로 인해) 큰 반응 시간을 설명 할 수 있으며 두 프로세스가 영향을받을 수 있으므로 체인에 haproxy를 추가 할 때 왜 더 나쁜지 확인해야합니다 .

haproxy에서 503을 얻는다는 것은 건강 진단에 응답하지 않은 서버를 잃어 버렸다는 것을 의미합니다. 이는 거대한 응답 시간 인 BTW와 일치합니다.

어떤 이유로 든 응용 프로그램이 모든 CPU를 먹고 동일한 CPU에 바인딩되어있는 경우 haproxy에 높은 예약 대기 시간을 초래할 수도 있습니다. CPU 사용량을 모니터링하고 각 프로세스가 실행중인 CPU를 확인해야합니다 (이 경우 "위쪽"사용). 이상적으로는 haproxy를 특정 코어 (작업 세트를 사용하여)와 응용 프로그램을 다른 코어로 강제 실행해야합니다. 높은로드를 달성하려면 코어에서 스레드 마이그레이션을 피하는 것이 중요하므로 새로운 인스턴스 각각을 전용 코어에서 실행해야합니다.

서버가 많은 메모리를 사용하는 경우 haproxy의 서버 maxconn 매개 변수를 사용하여 요청을 직렬화하고 maxqueue를 제거해야합니다.

당신의 haproxy 구성에서 볼 수있는 다른 것들 중에서도, 글로벌 maxconn은 거대하고 많은 의미를 가지지 않습니다.이 한계에 도달하려면 haproxy 용으로 약 9GB의 RAM이 필요합니다. 또한 프론트 엔드의 기본값이 2000 일 때 defaults 섹션에 maxconn 값을 설정해야합니다.이 값은 아마도 여러분이 시도하는 것보다 낮을 것입니다.

기본값 인 "maxconn 0", "maxqueue 0"및 "weight 1"은 제거해야하며 설정을 이해하는 데 어려움이 있습니다.

+0

평균 응답 시간이 500ms를 초과하지 않습니다. 동시 요청이 너무 많으면 응답 시간이 증가합니다. –

+0

전용 코어에 대한 좋은 조언. 문제는 연결 타임 아웃 옵션에 있었다고 생각합니다. 연결이 5 번에 설정되지 않으면 503이 haproxy에 의해 반환됩니다. 이 값을 50으로 늘렸고 응용 프로그램 자체와 동일한 동작을 얻었습니다. –

+0

OK 너무 느리게 응답하는 응용 프로그램에는 분명히 문제가 있습니다. 모든 스레드를 채우고 새 연결은 이전 연결이 해제 될 때까지 기다려야합니다. 애플리케이션에서 시간을 낭비하지 않습니까? 이 500ms는 정말 큰 것입니다. 5-50 MICRO 초가 더 적당 할 것입니다. –