큐잉하고 직렬화하고 있습니까?

우리는 다양한 서비스를 통해 메시지를 처리합니다 (하나의 메시지는 완료되기 전에 9 개의 서비스에 닿을 것입니다. 현재는 성능면에서 최악의 경우 (XML 데이터 계약 직렬화)와 최상의 경우 (메모리 내 MSMQ)를 조합했습니다.

메시지의 특성상 직렬화 된 데이터는 약 12-15 킬로바이트이며, 주당 약 4 백만 개의 메시지를 처리합니다. MSMQ의 영구 메시지는 우리에게 너무 느리고 데이터가 증가함에 따라 MSMQ의 메모리 매핑 파일에서 압력을 받고 있습니다. 서버는 16GB의 메모리 사용 및 큐잉을 위해 증가하고 있습니다. 컴퓨터가 스와핑을 시작하기 때문에 메모리 사용량이 많으면 성능이 저하됩니다. 이미 MSMQ 자체 정리 동작을 수행하고 있습니다.

우리가 여기서 잘못하고있는 부분이 있다고 생각합니다. 메시지를 유지하고 식별자를 대기열에 넣기 위해 RavenDB를 사용하려고 시도했지만 성능이 매우 느 렸습니다 (분당 1000 메시지). 그것이 개발 버전을 사용한 결과인지 확실하지 않지만 더 높은 처리량이 필요합니다 [1]. 이 개념은 이론적으로는 잘 작동했지만 성능은 과제에 미치지 못했습니다.

사용 패턴에는 라우터 역할을하는 하나의 서비스가 있으며,이 서비스는 모든 읽기를 수행합니다. 다른 서비스는 타사 후크를 기반으로 정보를 첨부하고 라우터로 다시 전달합니다. 대부분의 객체는 9-12 번 터치되지만 타사가 적절하게 응답 할 때까지 약 10 % 가이 시스템에서 잠시 동안 반복됩니다. 이러한 이유로 서비스의 우선 순위 필드를 활용함에 따라 현재 서비스가이를 설명하고 적절한 수면 동작을 갖습니다.

그래서 제 질문은 C # / Windows 환경에서 개별 디스크이지만 LAN 컴퓨터 사이에서 메시지를 전달하는 데 이상적인 스택은 무엇입니까? 일반적으로 XML 직렬화 대신 BinaryFormatter로 시작하지만 직렬화를 문서 저장소로 오프로드하는 것이 더 좋은 방법이라면 토끼 구멍입니다. 따라서 내 질문입니다.

[1] : 비즈니스의 본질은 메시지를 빨리 처리할수록 더 많은 돈을 벌 수 있음을 의미합니다. 우리는 일주일 후반에 메시지를 처리하는 것이 돈을 벌 가능성이 적다는 것을 경험적으로 증명했습니다. "분당 1000"의 성능은 매우 빠르지 만 실제로는 10k / 분 이상의 숫자가 필요합니다. 주당 메시지로 숫자를 제공한다고해서 해당 메시지를 처리하는 데 일주일 내내 있다는 의미는 아닙니다.

=============== 편집 :

추가 정보

의견을 바탕으로 몇 가지 설명을 추가하겠습니다.

• 직렬화가 병목 현상인지 확실하지 않습니다. 애플리케이션을 벤치마킹했으며 히트 그래프에 직렬화가 표시되지만 서비스 CPU 사용률의 2.5-3 %에 대해서만 책임이 있습니다.

• 나는 메시지의 영속성과 MSMQ의 오용에 대해 주로 우려하고 있습니다. 비 트랜잭션, 비 지속 메시지를 사용하여 큐잉 성능을 계속 유지할 수 있으며 최소한 지속성 메시지를 유지하여 재부팅 후에도 지속됩니다.

• RAM을 더 추가하는 것은 스톱 갭 측정입니다. 머신은 이미 4GB-> 16GB RAM에서 나갔으며 계속 추가하기 위해 중단하는 것이 점점 어려워지고 있습니다.

• 응용 프로그램의 스타 라우팅 패턴으로 인해 객체가 터지는 시간의 절반이 대기열로 푸시되어 전혀 변경되지 않습니다. 이것은 다른 곳에서 일종의 키-값 저장소에 저장하고 단순히 메시지 식별자를 전달하기 위해 다시 자신에게 적합합니다 (IMO).

• 스타 라우팅 패턴은 응용 프로그램에 필수적이며 변경되지 않습니다. 모든 방식의 조각이 비동기 방식으로 (폴링 방식으로) 작동하고 재시도 동작을 한 곳에서 중앙 집중화하려고하기 때문에 애플리케이션을 지네로 지을 수 없습니다.

• 응용 프로그램 논리는 C #으로 작성되고 개체는 변경 불가능한 POCO이며 대상 배포 환경은 Windows Server 2012이며 특정 소프트웨어가 Linux에서만 지원되는 경우 추가 컴퓨터를 세워 둘 수 있습니다.

• 저의 목표는 최소한의 자본 지출로 메모리 풋 프린트를 줄이고 내결함성을 높이면서 현재 처리량을 유지하는 것입니다.

관심있는 큐 벤치 마크는 다음과 같습니다. MSMQ는 초당 10K 메시지를 처리 ​​할 수 ​​있어야합니다. 구성 문제 일 수도 있고 클라이언트가 대기열을 읽지 못하는 것일 수도 있습니다. 또한 벤치 마크 (초당 약 100K 메시지)에서 ZeroMQ가 엄청나게 빠르다는 점에 주목하십시오. 지속성 옵션을 제공하지는 않지만 성능이 현명한 곳으로 안내해야합니다.

우리는 몇 년 전 대기중인 메시지 시스템 (우리의 경우 오디오 지문)으로 다소 비슷한 상황을 겪었습니다. 큐에 넣은 데이터 패킷의 지속성을 강력하게 평가했지만 디스크에 모든 것을 큐에 넣고 디스크에서 큐를 소비하는 것은 매우 비싸다는 것을 알았습니다.

메모리 기반 대기열로 전환하면 성능은 뛰어 났지만 큰 문제가있었습니다. 가끔씩 대기열 소비자는 상당한 시간 동안 사용할 수 없게되었고 (이 경우 소비자 및 생산자 요소는 WAN을 통해 연결됨) 생산자의 대기열은 관리가 불가능하고 귀하의 경우처럼 커질 것입니다. 메모리 소비가 매우 높으면 스와핑 중 과도한 메모리 스 래싱으로 인해 시스템이 완전히 크롤링됩니다.

우리는 우리가 세례를 잡은 대기열을 설계했습니다 VMQueue (가상 메모리 대기열의 경우 소급하여 매우 나쁜 이름). 이 대기열의 개념은 소비자 프로세스가 대기열에있는 요소 수를 특정 수준 이하로 유지할 수있을 정도로 빠르게 처리하는 경우 기본적으로 메모리 성능이 동일하다는 것입니다. 기반 대기열. 그러나 소비자가 느려지거나 사용할 수 없게되고 생산자 큐가 특정 크기로 커지면 큐는 디스크를 통해 디스크간에 요소를 자동으로 페이징하기 시작합니다 (BinaryFormatter그런데 직렬화). 이 프로세스는 메모리 사용을 완전히 제어하고 페이징 프로세스는 메모리로드가 많은 동안 발생하는 가상 메모리 스와핑보다 빠르거나 적어도 훨씬 빠릅니다. 소비자가 대기열을 임계 값 미만으로 비우면 순수한 메모리 기반 대기열로 다시 작동합니다.

시스템이 충돌하거나 재부팅되면 큐는 디스크에 저장된 모든 페이징 된 요소를 복구 할 수 있으며 충돌 전에 메모리에 남아 있던 요소 만 손실합니다. 충돌 또는 재부팅 중에 제한된 수의 패킷을 잃을 여유가 있다면이 대기열이 도움이 될 수 있습니다.

관심이 있으시면 VMQueue클래스 소스 코드를 공유하여 함께 사용할 수 있습니다. 대기열은 Serializable로 표시된 모든 클래스를 허용합니다. 대기열을 만들면 페이지 크기를 요소 수로 설정합니다. 클래스 인터페이스는 사실상 표준 큐 클래스와 동일합니다. 그러나 코드는 매우 오래되었으므로 (.net 1.1) 일반적인 인터페이스가 불행히도 존재하지 않습니다.

입증 된 MSMQ 기술에서 전환하는 것이 큰 선택이지만,이 대기열은 거의 6 년 동안 안정적으로 작동 해 왔으며 생산 시스템이 몇 주 동안 오프라인 상태 인 시나리오에서 생존하고 복구 할 수있었습니다! 관심이 있으시면 알려주십시오. :)

HP ProLiant ML350G5 시스템 은 분당 82k 트랜잭션을 얻습니다. 즉, 언급 한 "10k / 분"처리량의 8 배 이상입니다.

성능 : 82,774 tpmC

또한 솔직히 말하면 64GB 또는 128GB의 RAM을 사용했습니다 .RAM은 저렴합니다. Greenspun 은 "RAM을 던지다"와 "현명한 MIT 교육을받은 사람이 그것을 최적화하도록한다"의 차이를 지적하고 RAM이 이긴다.

그는 64GB RAM이 장착 된 SQL Server 시스템과 ASP.NET 페이지를 실행하는 소수의 프런트 엔드 시스템으로 끝났습니다 ... swaptree.com 사이트는 현재 40 만 명 이상의 사용자를 처리하고 있습니다 (빠르게 증가). 어려움없이 ...

참고 "시스템이 이미 16GB RAM으로 갔다"는 기사는 64GB RAM에서 400k 명의 사용자를 처리하고있는 서버를 가리키고 있습니다.