Amazon ELB를 치면 JMeter 처리량이 떨어집니다.

Question

Amazon의 AWS 서버에서 웹 응용 프로그램을 호스팅하고 있습니다. 현재 JMeter를 사용하여 응용 프로그램을로드 테스트하는 중입니다. 내 주요 문제는 Elastic Load Balancer (ELB)를 통해 Amazon 서버를 직접 방문하는 것보다 서버를 직접 타격 할 때 - 처리량이 모자라는 것 같습니다.

웹 응용 프로그램에 직접 연결되면 서버 당 50 RPS의 처리량을 얻을 수 있습니다. 나는 아마존의 ELB를 통해 내 웹 응용 프로그램을 공격하는 경우

- 난 (전체) 50 RPS의 최대 처리량을 달성 할 경우에만 수 있어요

나는 다른 사람이 비슷한 문제를 경험하고 궁금 할 때 아마존을 통해 JMeter를을 사용하여 부하 테스트 ELB.

내 웹 응용 프로그램은 HTTP 요청을 통해 콘텐츠 (~ 150KB)를 다운로드 할 수있는 REST 응용 프로그램입니다.

"-Dsun.net.inetaddr.ttl = 0"플래그와 함께 Jmeter를 실행하고 10 개의 스레드로 실행하고 있습니다. 나는 다른 컴퓨터에서 여러 클라이언트로 이러한 테스트를 실행 해 보았습니다.

사전에 도움을 주셔서 감사합니다.

Answer 1

로드 균형 조정 도구는 원본에 따라 트래픽을 조정하는 메커니즘이 다를 수 있으므로 테스트가 까다로울 수 있습니다. 요청의 출처를 구별하고 이전 요청을 처리 한 동일한 호스트로 리디렉션하는 가장 일반적으로 사용되는 방법은 쿠키입니다. HTTP Cookie Manager을 살펴보면 쿠키를 올바르게 조작 할 수 있으며 사용 사례에 따라 각 테스트 스레드 또는 스레드 그룹마다 다른 쿠키를 사용하는 것보다 확실합니다. 다른 비정상적인 영역은 출발지 호스트 IP입니다. 로드 밸런서 뒤에있는 다른 서버를 공격하려면 각 테스트 스레드를 다른 IP 주소에 바인드해야 할 수도 있습니다. Amazon LBs와 관련하여 DNS와 관련하여 몇 가지 문제가있을 수 있습니다. 유용한 가이드 how to test Amazon ELBs

Answer 2

대부분의 원인은 jmeter에 의한 DNS 캐싱입니다. ELB는 자동 확장 설정 방법에 따라 추가 서버의 IP를 반환하지만 JMeter는 이러한 추가 서버를 사용하지 않습니다. 이 문제는 Jmeter가 DNS 결과를 캐싱하지 않음으로써 해결할 수 있습니다 ...

ELB는 IP가 아닌 이름이며 DNS 캐싱으로 인해 어려움을 겪을 수 있습니다. 사용 확인 "-Dsun.net.inetaddr.ttl = 0"JMeter를

http://wiki.apache.org/jmeter/JMeterAndAmazon

Answer 3

정말 늦게 반응을 시작하고, 원래의 질문보다 약간 다른,하지만 난이 그것으로 다른 사람을 도울 수 있기를 바랍니다 때 그것을 모두 똑바로하기 위해 나를 데려 갔다. 저의 원래 문제는 ELB의 결과로 처리량이 감소하지 않았지만 HTTP 503 오류가 도입되었습니다. 실제로 ELB는 웹 응용 프로그램을 직접 쿼리하는 것과 비교하여 처리량을 늘렸지만 1 시간 테스트를하더라도 결과가 산발적으로 나타났습니다.

먼저 ELB에는 2 단계로드 밸런싱이 수행됩니다. 첫 번째로드 밸런스는 ELB 자체에서 발생합니다. 이는 제공하는 ELB에 대해 AWS가 제공 한 호스트 이름에 여러 IP 주소를 연결하여 수행됩니다. 그런 다음 두 번째 단계는 ELB 뒤에있는 응용 프로그램 인스턴스에서 수행됩니다.

SO 신을 괴롭히지 않고이 글은 정말 도움이되는 기사입니다.

https://blazemeter.com/blog/dns-cache-manager-right-way-test-load-balanced-apps

거기에 가장 도움이되는 정보

는 JMeter가의 DNS 캐쉬 관리 모듈을 사용하는 것이 었습니다. 이렇게하면 여러 DNS 서버를 쿼리하고 DNS 캐시를 지울 수 있습니다.

그 모듈을 구현 한 다음, ELB 호스트 이름에 속하는 두 개의 IP 주소를 필터링하여 Wireshark를 설정했습니다. 분명히 두 IP 주소를 모두 조회했지만 분명히 선호했습니다.

큰 차이를 만들지는 않았지만, 적어도 짧은 테스트 이상은 아니 었습니다.

실제 차이 (처리량 2-3 배)는 ELB 상태를 조정할 때 나타납니다. 처음에는 높은 오류율을 보였지만 건강에 좋지 않은 문턱 값과 건강 검진 간격을 줄이면 오류율이 크게 떨어졌습니다.

또한 다른 모든 테스트는 60-90 분의 지속 시간 이었지만이 테스트는 8 시간이었습니다. 괜찮은 처리량으로 시작한 다음 빠르게 (2/3 정도) 떨어졌습니다. 약 20 분 이상 경과하면 처리량이 다시 올라가고 테스트가 끝날 때까지 ELB가없는 상태에서 약 5 배의 처리량이 지속되었습니다 (이는 곧 처리량이 감소했을 때와 유사합니다). 이 검사를 시작한 후).