pushtechnology 확산 서버에서의 흐름 제어 게시 클라이언트 업데이트 지연

Question

제어 클라이언트는 각기 다른 토픽에 대해 확산을 통해 클라이언트에 2 초당 200-250 바이트의 크기로 100 개의 업데이트를 전송합니다 (2 초 내에 항목 당 하나의 업데이트). 이 문제는 약 20-30 분 동안 전송 한 후 한 번 발생하며 흐름 제어로 인해 흐름 제어가 시작되고 업데이트는 1 ~ 2 시간 후 5ms에서 100ms로 지연됩니다. 제어 클라이언트를 확산에 게시하기위한 흐름 제어를 피할 수있는 방법이 있습니까?

maxqueuesize은 10000 확산 API 로그를 설정 : 압력 = 0.04622500000000004 => 잠 4 MS

Answer 1

Flow Control 위해 버전 5.1에서 자바 클라이언트와 그것은 방지하기 위해 존재하는 버전 5.5의 .NET 클라이언트에 도입 내부 대기열 오버플로. 그렇지 않으면 클라이언트 세션을 닫습니다. 더 깊은 근본적인 문제를 배증하는 증상입니다.

것은 몇 가지 이유가 일어나고 :

• 귀하의 확산 서버는 워크로드와 유지되지 않습니다. 이런 일이 몇 시간 후에 발생하면 서버 JVM이 가비지 수집에 너무 많은 시간을 소비하는지 궁금하게 생각합니다. Java Missions Control 그 질문에 대답하는 것이 좋습니다.

• 우리는이 작업이 이중 역할 (예 : 주제를 만들고 업데이트하며 Missing Topic Notifications과 같은 이벤트에 반응합니다. 흐름 제어는 큐 채도와 만족되지 않은 요청의 수를 포함하여 여러 가지 기능입니다. 이 경우 각 역할에 대한 개별 세션을 고려하십시오.

두 번째로 이동하기 전에 먼저 & 첫 번째 가능성을 고려하고 조사하십시오. 문제가 계속되면하는 것이 2의 경우처럼