Plex는 속도가 느려지기 전에 동시 사용자를 몇 명까지 처리할 수 있나요?

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

유용한 보편적 Plex 사용자 한도는 없습니다. 안정적인 동시 재생 한도는 스토리지, 네트워크 또는 트랜스코딩의 여유가 사라지기 전에 통과하는 실제 세션 조합 중 가장 큰 규모입니다.

Direct Play 사용자 10명이 까다로운 원격 트랜스코딩 2명보다 부하가 적을 수 있으며, 안정적으로 재생되는 서버도 여러 시청자가 동시에 재생을 시작하거나 탐색하면 버벅일 수 있습니다. 실제 재생 모드, 비트레이트, 자막 및 HDR 경로, 원격 업로드 사용량을 확인하세요. 그런 다음 대표 세션을 한 번에 하나씩 추가하고, CPU 모델이나 계정 수로 용량을 추정하는 대신 반복적으로 재현되는 첫 번째 병목에서 멈추세요.

계정이 아니라 재생 경로를 계산하세요

Plex에 액세스할 수 있는 사람 수가 동시 작업 수를 의미하지는 않습니다. 실제 사용량이 가장 많은 시간대를 관찰하는 것부터 시작하고, 모든 활성 세션을 Direct Play, Direct Stream, 오디오 전용 변환 또는 비디오 트랜스코딩으로 분류하세요. 이러한 모드는 서버 리소스를 매우 다르게 사용합니다.

동시에 10개 이상의 세션이 실행되더라도 Direct Play, 리먹스, 오디오 변환 및 비디오 트랜스코딩 경로가 각각 몇 개나 활성화되었는지에 따라 한도가 크게 달라질 수 있습니다. 단순한 사용자 수만으로는 성능 저하 지점을 예측할 수 없습니다.

전체 가구 구성원이나 친구 목록이 아니라, 현실적으로 발생 가능한 최대 동시 접속량을 기준으로 테스트 세트를 구성하세요. 6명이 거의 동시에 시청하지 않고 모두 Direct Play를 사용한다면, 4K 트랜스코딩 3개가 동시에 실행되는 경우와는 전혀 다른 용량 문제입니다.

여유가 가장 먼저 사라지는 공유 리소스를 찾으세요

동시 세션은 미디어 스토리지, 서버 네트워크 인터페이스, 오디오 및 자막 처리를 위한 CPU 작업, 트랜스코딩 임시 공간, 변환에 사용되는 하드웨어 비디오 엔진을 공유합니다. 한도는 사양 수치가 가장 높은 구성 요소가 아니라, 실제 조합에서 필요한 리소스 중 가장 먼저 한계에 도달하는 리소스가 결정합니다.

동시 접속이 많은 Plex 작업에서는 드라이브, 네트워크, 트랜스코딩 및 내부 데이터 경로에서 여러 병목이 드러날 수 있습니다. 소규모 홈 서버에서도 동일하게 여러 리소스를 함께 살펴보세요.

세션을 한 번에 하나씩 추가하면서 미디어 디스크 지연 시간, 네트워크 처리량, CPU, GPU 비디오 엔진, 메모리 압박 및 트랜스코딩 속도를 기록하세요. 재생 품질이 저하되는 시점과 일관되게 여유가 사라지는 첫 번째 지표가 실제 용량의 경계입니다.

원격 사용자는 업로드라는 별도의 한도를 추가합니다

로컬 스트림은 빠른 LAN 내부에서만 처리될 수 있지만, 모든 원격 스트림은 가정의 인터넷 업로드 대역폭을 공유합니다. 강력한 서버라도 원본 또는 트랜스코딩된 비트레이트의 합계가 다른 가정 내 트래픽을 제외하고 남은 업로드 용량을 초과하면 사용자 입장에서는 느려질 수 있습니다.

원격 용량을 계산할 때는 네트워크 용량과 트랜스코딩 용량을 별도의 한도로 취급해야 합니다. 더 빠른 GPU라도 과부하가 걸린 WAN 업링크가 더 많은 데이터를 전송하도록 만들 수는 없습니다.

브라우저에서 로컬 탭을 여러 개 여는 방식이 아니라, 집 밖에서 원격 동시 접속을 테스트하세요. 업로드가 먼저 한계에 도달한다면 CPU를 추가로 구매하기 전에 원격 비트레이트를 낮추거나 연결을 개선하세요. 업로드에 여유가 있고 트랜스코딩 속도만 떨어진다면 컴퓨팅 경로가 더 강한 제한 요소입니다.

-15% OFF

재생 시작과 탐색에서 순간적인 여유가 드러납니다

여러 사용자가 동시에 재생을 시작하거나 탐색하는 상황보다 안정적인 재생 상태가 더 쉬운 경우가 많습니다. 이러한 순간에는 작업이 안정될 때까지 버스트 읽기, 새로운 버퍼 생성, 메타데이터 요청 및 새로운 네트워크 흐름이 발생합니다.

고정된 스트림 수만으로는 동시 트랜스코딩 계획을 세우기에 충분하지 않습니다. 동시에 시작될 수 있는 파일 형식, 목표 비트레이트, 자막 경로 및 변환 작업을 반드시 수용 테스트에 포함해야 합니다.

목표 세션 조합이 이미 활성화된 상태에서 첫 화면이 표시되기까지 걸리는 시간과 탐색 후 복구 시간을 기록하세요. 동기화된 재생 시작에서만 문제가 발생한다면, 한도는 지속적인 컴퓨팅 성능이 아니라 순간적인 스토리지 처리량, 앱 상태 지연 또는 대기열일 수 있습니다.

백그라운드 작업은 같은 여유를 줄일 수 있습니다

스캔, 백업, 다운로드 및 분석 작업은 활성 시청자에게 필요한 것과 동일한 스토리지, CPU, 메모리 또는 네트워크 용량을 사용할 수 있습니다. 따라서 조용한 벤치마크를 통과한 서버도 실제 가정 내 최대 사용량에서는 한계를 초과할 수 있습니다.

필수가 아닌 유지 관리 작업을 일시 중지한 상태와, 대표적인 백그라운드 작업 하나를 실행한 상태에서 목표 세션 조합을 각각 테스트하세요. 두 결과의 차이를 통해 더 큰 하드웨어가 아니라 일정 조정으로 여유를 회복할 수 있는지 확인할 수 있습니다.

백그라운드 작업을 일시 중지해도 재생이 계속 실패한다면 동시 접속 한도를 재생 경로에 유지하세요. 문제가 사라진다면 경쟁 작업의 일정을 조정하거나 분리하여, 비용이 더 낮은 서버 기준을 유지하세요.

통과한 작업 정의와 실패한 작업 정의를 런북에 함께 기록하세요. 그러면 클라이언트, 코덱, 스토리지 풀 또는 예약 작업이 변경된 후에도 운영 한도를 재현할 수 있습니다.

반복 테스트를 통해 운영 한도를 설정하세요

유용한 동시 접속 한도는 30초 동안 재생된 가장 높은 수치가 아니라, 반복적으로 안정적인 동시 세션 조합입니다. 대표적인 콘텐츠를 까다로운 장면까지 재생하고 한 번 탐색한 다음, 온도, 대기열 및 트랜스코딩 속도가 안정될 때까지 충분히 시스템을 관찰하세요.

원격 4K 작업 테스트는 Direct Play, 업로드 및 트랜스코딩 요구 사항을 파악한 후에야 하드웨어 용량을 산정하므로, 동시 접속 한도가 계정 수가 아닌 측정된 작업량에 연결된 상태로 유지됩니다.

통과한 세션 조합과 첫 번째 실패 원인을 문서화하세요. Direct Play 스트림을 하나 더 추가했을 때 네트워크가 포화된다면 한도는 네트워크 기반입니다. 트랜스코딩을 하나 더 추가했을 때 실시간 처리 속도 아래로 떨어진다면 컴퓨팅 기반입니다. 이 수치를 영구적인 값으로 간주하지 말고, 주요 클라이언트, 코덱, 스토리지 또는 네트워크가 변경될 때마다 다시 테스트하세요.

지원 및 팁

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.