홈 서버는 재생 품질이 저하되기 전에 Jellyfin 동시 스트리밍을 몇 개까지 지원할 수 있을까요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How Many Concurrent Jellyfin Streams Can a Home Server Sustain Before Playback Degrades? - Zima Store Online

Jellyfin에는 보편적인 스트림 수 기준이 없습니다. 지속 가능한 동시 재생은 가장 까다로운 일반 워크로드가 클라이언트 버퍼 여유를 반복적으로 소진하는 시점에 끝납니다.

Direct Play 클라이언트가 대부분인 6개의 세션을 처리하는 홈 서버가 자막 번인을 사용하는 원격 HDR 스트림 하나보다 부하가 적을 수 있습니다. 가장 바쁜 일반 사용 시간대에 겹치는 재생 모드, 변환 단계, 다른 서비스의 부하를 측정하세요. 이렇게 하면 오해의 소지가 있는 CPU당 사용자 수가 아니라 실제 워크로드에 맞춘 실용적인 한계치를 얻을 수 있습니다.

사용자 수 대신 재생 모드를 세세요

각 Jellyfin 세션은 서로 다른 경로로 처리됩니다. Direct Play는 주로 파일을 읽어 전송하는 반면, 리먹스, 오디오 변환, 비디오 트랜스코딩은 점점 더 많은 작업을 추가합니다. 경로를 분류하지 않고 세션 수만 세면 미디어 파이프라인에 실제로 입력되는 부하를 파악할 수 없습니다.

유용한 워크로드 표에는 대표적인 각 클라이언트와 원본 파일에 대한 트랜스코드 워크로드를 기록해야 합니다. 코덱, HDR 상태, 자막, 해상도, 원격 비트레이트도 포함하세요.

모든 세션에 이름이 지정된 분류가 부여된 뒤에야 세션 수가 의미를 갖습니다. 단순한 Direct Play 스트림 2개를 이미지 자막을 사용하는 4K HDR 변환 1개와 같은 비중으로 계산해서는 안 됩니다.

가장 까다로운 일반 경로가 첫 번째 한계치를 결정합니다

동시성은 각 경로에서 사용하는 리소스만큼만 증가합니다. Direct Play 스트림은 스토리지 읽기와 네트워크 전송 부하를 추가하지만, 트랜스코드는 디코딩, 필터, 톤 매핑, 인코딩, 임시 스토리지, CPU 폴백 용량까지 사용할 수 있습니다.

단일 GPU 또는 CPU 사용률에 의존하지 말고 사용률과 포화도를 측정해 실제로 활성화된 리소스를 확인하세요. 다른 구성 요소에 아직 여유가 있더라도 한 단계가 실시간 처리에 실패하면 대기열이 형성될 수 있습니다.

반복적으로 대기열이 발생하거나 버퍼 여유가 감소하는 최초의 지점이 해당 워크로드에서 유효한 한계치입니다. 다른 곳에 사용되지 않은 더 빠른 리소스가 있다고 해서 이 한계치가 높아지지는 않습니다.

원격 및 공유 워크로드는 경계선을 바꿉니다

원격 세션은 일반적으로 로컬 클라이언트보다 업로드 대역폭이 적고 지연 시간 변동이 큽니다. 인접한 백업, 인덱서 또는 다운로드 작업이 같은 스토리지나 네트워크 경로를 사용할 수도 있으며, 시청자가 재생을 시작하거나 탐색하는 바로 그 순간에 여유 용량을 줄일 수 있습니다.

미디어와 클라이언트 정책을 동일하게 유지한 상태에서 다중 앱 리소스 모델을 사용해 로컬 환경과 원격 환경을 비교하세요. 원격 환경에서만 버퍼 여유가 줄어든다면, 그 한계는 미디어 엔진이 아니라 처리 경로나 업로드 대역폭에 있습니다.

따라서 동일한 서버에도 여러 한계치가 존재합니다. 로컬 Direct Play, 로컬 트랜스코드, 원격 전송, 그리고 동일 서버에 배치된 서비스가 가장 많이 실행되는 시점의 워크로드가 각각 별도의 한계치를 가집니다.

-15% OFF