2010-08-08 2 views
1

현재 다양한 출처의 방문을 기록하는 추적 서비스를 보유하고 있습니다. 때때로 우리는 방문을 기록하고 고객에게 리디렉션하거나 고객이 우리에게 방문보고를 요청할 수있게합니다. 이 아키텍처는로드 밸런서 뒤에 구성된 두 개의 작업자 상자입니다. 이 시스템은 Amazon EC2를 사용하여 설정되며 사용되는로드 밸런서는 Amazon의 Elastic LB입니다.고성능 고 가용성 추적 시스템

몇 가지 벤치마킹 테스트를 수행했으며 중요한 네트워크 대기 시간을 발견했습니다. 로드 밸런서를 통한 트래픽은 상자를 직접 누르는 것보다 적어도 2 배 지연됩니다.

  • 누구든지 이러한 문제가 발생했는데 해결을 시도 했습니까? Amazon EC2 특정 문제입니까?
  • 내 네트워크 대기 시간을 크게 줄이는 다른 아키텍처가 사용 중입니까? 예 : 트래픽을로드 밸런서를 거치지 않고 엔드 포인트 서버에 직접 연결하는 HA를 사용합니까? 시간을 투자하기 전에 다른 사람들이 생각하는 것을 듣고 싶었습니다.

덕분에 많이 시간 내, 산토

답변

0

처음에는 ELB의 성능이 좋았다는 것을 고려해야합니다. 왜 그런지 물어 보지 마세요, 그렇습니다.로드 밸런서의 온난화?

또한 실제로 전송 한 트래픽의 양에 따라 달라집니다. ELB가 제공되는 하드웨어는 일반적인 작은 인스턴스처럼 보입니다. 따라서 처리량은 ~ 25 MBit (마지막으로 확인)에서 제한됩니다. 더 많은 것을 원하면 헌신적으로 가십시오.

결국 나는 또한 당신이 전용 인스턴스에서 Haproxy를 보길 제안합니다. 나는 약간의 딜레이를 기대하고, 2 배의 딜레이는 비현실적으로 들린다. 어쩌면 다른 작은 인스턴스를 사용하여 ELB에 직접 벤치 마크 한 다음 c1.medium을 시도해보십시오.