채팅 예제와 비슷한 긴 폴링을 사용하여 Play 1.2.4 응용 프로그램을 개발 중입니다. JMeter로 부하 테스트를 해왔고 300 명 이상의 청취자가있을 때 내 서버가 4 초 이상 응답해야하는데 이는 내 요구에 너무 많이 들거나 응답을 수신하지 못합니다. 모든 응답을 1 초 안에 받아야합니다.긴 폴링에 연결 제한이 있습니까?
긴 폴링에 연결 제한이 있습니까? 특별한 구성이나 서버가 필요합니까?
특별한 구성이 필요하지,이 서버에서 CPU/RAM 단지 문제 미리
감사합니다, 플러스는 컨트롤러 호출 (DB에 얼마나 많은 요청 등)를 처리하는 데 얼마나 걸립니까.
Play는 상태가 저장되지 않으므로 시간 초과가 발생하면로드 밸런서 뒤에 두 번째 서버를 추가하면 문제가 해결됩니다. 의견에
편집 :
이 발생하는 주요 문제는 재생 300 사용자에게 이벤트를 전파하는 데 오래 걸리는 것입니다. Chat 샘플은 메모리 내 시스템을 사용하여 전달을 수행하고 각 구독자에게 메시지를 순차적으로 전달하므로 예상대로입니다.
채팅 방식에는 다른 방법이 있습니다. 두 번째 서버를 사용하는 경우 ArchivedEventStream이 Play 인스턴스 JVM에 로컬로 저장되기 때문에 메시지를 공유하지 않습니다.
성능을 더 높이려면 게시/가입 단계를 Redis와 같은 외부 Message Queue 도구로 이동해야합니다. 이렇게하면 동일한 메시지를 공유하면서 추가 인스턴스를 추가 할 수있는 이점이 있습니다.
Play 서버의 긴 폴링에 대한 연결 제한에 도달 한 것 같지 않습니다. 오히려 응답 시간이 저하되는 일종의 병목 현상이 발생하고 있습니다.
JMeter 테스트를 실행하는 시스템의 한계에 도달했을 가능성이 높습니다. GUI 모드에서 실행중인 경우이 증가 가능성이 있습니다. 여러 대의 컴퓨터를 사용하여 테스트를 반복하거나, 동시에 두 대의 컴퓨터에서 동일한 테스트를 실행하거나, 하나의 테스트가 실행 중일 때 동일한 결과를 보여 주면 문제가 있는지 여부를 확인할 수 있습니다 Play 서버가 아니라 테스트 자체. 그러나 두 가지 테스트를 실행하면 더 나쁜 결과가 나타나는 경우 서버에 문제가있는 것입니다. 진입로를 사용하는 것을 잊지 마십시오. 그러면 상황이 느려지는 지점을 파악하는 데 도움이되며 이는 조정에 유용합니다.
JMeter 한도에 도달 한 다음 명령 줄에서 실행 해보는 것이 훨씬 더 효율적입니다. 인터페이스가 실제로 필요한 경우 적은 수의 수신기를 사용해보십시오. 문제가있는 부분입니다.
시간 초과가 발생하지 않습니다. 문제는 300 명 이상의 사용자가있을 때 모든 사용자에게 응답하기 위해 3 초 이상 긴 폴링이 필요하다는 것입니다. 내 요구에 너무 많이 부합합니다. –
아마도 사용중인 코드를 넣어야합니다. 우리는 요청에 매우 많은 작업을하지 않는 한 그렇게해서는 안되기 때문에 당신을 도울 수 있습니다. –
내 애플리케이션은 Play 1.2의 채팅 예제 [http://www.playframework.org/documentation/1.0/samples#aChata](http://www.playframework.org/documentation/1.0/samples#aChata)를 기반으로합니다. .4. 그리고 나는 그 예를 가지고 시험을했다. –