문제

동시에 처리 할 100 개 이상의 비디오 스트림 채널이 있습니다. 비디오를 캡처하고 썸네일을 생성하여 웹 서비스로 제공해야합니다. 축소판 생성의 경우 JMF 등을 사용할 수 있습니다 (생성 및 액세스 방법에 대한 또 다른 게시물이 있음을 알았습니다. 더 큰 이미지 파일의 더 나은 품질의 썸네일). 그러나 내 관심사는 : 어떻게 확장 하는가? Java EE EJB 또는 간단히 Java SE 스레드? 단점과 장점은 무엇입니까? EJB를 사용하여 수평으로 확장하는 방법은 무엇입니까?

나는 확장 성 문제에 익숙하지 않으며, 당신의 친절한 제안에 정말 감사합니다.

감사.

도움이 되었습니까?

해결책

동의합니다 ... 스레드는 단일 시스템에서 스케일링하는 데 도움이됩니다. 다른 기계에서 확장하려면 Terracotta를 사용하십시오.

다른 팁

Java SE 스레드는 단일 시스템에서 확장하는 데 도움이 될 수 있지만 다른 컴퓨터에서 수평으로 확장해야한다면 EJB는 한 가지 방법이 될 것입니다.

그것이 나라면, 아마도 필요에 따라 많은 기계에서 실행될 수있는 별도의 웹 서비스 계층으로 농장 한 다음 해당 머신간에 균형을 줄일 것입니다.

이 상황에서 EJB를 사용해야 할 이유가 없습니다. 병목 현상이 어디에 있는지 스스로에게 물어봐야합니다. 내 베팅은 비디오 처리와 관련이 있습니다. 나는 당신의 응용 프로그램을 프로필하고 처리하는 것보다 타임 슬라이스를 기다리는 데 더 많은 시간을 소비하기 전에 얼마나 많은 스레드가 처리 될 수 있는지 확인합니다. 더 많은 스레드를 추가하면 더 많은 처리량이 추가되지 않습니다. 그 시점에서 당신은 기계가 무엇을 할 것인지, 특정 처리량을 유지하는 데 필요한 기계 수를 알고 있습니다. 기계를 통해 어떻게 확장 하는가는 또 다른 질문입니다.

이것들은 두 가지 뚜렷한 문제입니다.

캡처/처리는 렌더 팜과 같은 문제처럼 들립니다. 그것들은 사소한 수평으로 스케일링됩니다. 대부분의 솔루션에는 작업 대기열이 포함되므로 Java에서는이 작업을 수행 할 필요조차 없습니다. 원하는 간단한 솔루션을 찾으십시오. "렌더 팜 ffmpeg"또는 그와 같은 것들이 Google에서 결과를 산출해야합니다.

'웹 서비스로 제공하는'부분은 다소 정의되지 않았습니다. 해당 비디오가 적합하기를 원한다면 HTTP 서버에 올릴 수 있으시면 쉽게로드 균형을 잡을 수 있으므로 수평으로 확장 가능한 스토리지 속도 또는 네트워크 대역폭이 첫 번째 병목 현상이 될 수 있습니다.

공식적인 j2ee 스택을 남겨 두십시오.

오히려, X 수의 JMS와 대화하는 멋진 메시지 대기열은 y 스레드 수를 소비자로 실행합니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top