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

모든 홈 서버가 처리할 수 있는 동시 Immich 사용자 수를 나타내는 유용한 보편적 수치는 없습니다. “사용자 한 명”이 유휴 상태에서 둘러보기, 얼굴 검색, 대용량 업로드, 동영상 재생, 또는 여러 백그라운드 작업의 동시 실행을 의미할 수 있기 때문입니다.

용량은 자체 응답 시간 및 오류 기준을 충족하면서 반복적으로 처리할 수 있는 가정 내 최대 워크로드로 측정해야 합니다. 조용한 상태의 기준선을 설정하고, 현실적인 혼합 작업을 재현하며, 동시성을 통제된 단계로 높이고, 가장 먼저 포화되는 리소스를 관찰하세요. 이렇게 하면 근거 없이 만들어 낸 사용자 제한 대신 하드웨어와 라이브러리에 맞는 신뢰할 수 있는 용량 범위를 얻을 수 있습니다.

사용자 수를 세기 전에 “느려진다”의 의미를 정의하세요

타임라인 열기, 오래된 앨범 불러오기, 검색, 동영상 재생, 여러 파일의 일괄 업로드 등 집에서 중요한 사용자 동작을 몇 가지 선택하세요. 테스트 전에 허용할 수 없는 지연 시간, 시간 초과, 업로드 실패, 재생 끊김, 또는 사용자가 멈춘 뒤에도 계속 증가하는 대기열 등 실패의 기준을 정하세요.

기록하지 않은 상태에서 포그라운드 작업과 백그라운드 작업을 섞지 마세요. 썸네일 생성, 동영상 트랜스코딩, 얼굴 처리, Smart Search, 라이브러리 스캔, 데이터베이스 유지 관리, 백업은 활성 사용자가 사용하는 것과 동일한 CPU, 메모리, 디스크, 네트워크 리소스를 소비할 수 있습니다. 대규모 가져오기가 진행 중인 상태에서 수행한 “4명 사용자” 테스트는 안정된 라이브러리를 4명이 둘러보는 테스트와 다른 워크로드입니다.

각 결과와 함께 하드웨어, Immich 버전, 데이터베이스 위치, 스토리지 유형, 네트워크 연결, 라이브러리 크기, 활성 백그라운드 작업을 기록하세요. 이러한 맥락이 없으면 업그레이드 후 또는 다른 홈 서버와 동시성 수치를 의미 있게 비교할 수 없습니다.

백그라운드 작업을 통제한 상태에서 1인 기준선을 측정하세요

시스템이 알려진 상태에 있을 때 시작하여 대표적인 사용자 여정 하나를 측정하세요. 클라이언트 응답 시간과 함께 서버 CPU, 메모리 압박, 디스크 지연 시간 또는 사용률, 네트워크 처리량, 데이터베이스 활동, 그리고 관찰할 수 있는 Immich 워커 대기열을 기록하세요.

워크로드, 테스트 기간, 성공 기준이 명확할 때만 용량을 의미 있게 설명할 수 있습니다. 워크로드 기반 용량 테스트를 사용해 1인 기준선을 저장한 다음, 동시성이 증가할 때 지연 시간, 처리량, 오류가 어떻게 변하는지 측정하세요.

사용자 한 명만으로도 이미 느리다면 동시성 테스트를 중단하세요. 먼저 단일 사용자 병목을 해결해야 합니다. 세션을 더 추가하면 기존 스토리지, 데이터베이스, CPU, 네트워크 또는 구성 문제만 확대될 뿐이며, 서버의 실제 확장 동작에 대해서는 거의 알려 주지 못합니다.

현실적인 동시성을 통제된 단계로 높이세요

각 단계 사이에서 작업 구성을 비슷하게 유지하면서 사용자 또는 스크립트로 실행되는 클라이언트 세션을 점진적으로 추가하세요. 가정 환경에서는 작은 기준선에서 활성 세션 수를 두 배씩 늘리는 방식이 유용할 수 있지만, 정확한 숫자보다 중요한 것은 동시성만 변경하고 워크로드 정의를 일정하게 유지하는 것입니다.

테스트 전에 지연 시간, 오류, 처리량의 한계를 정의하고, 단일 엔드포인트를 집중적으로 호출하는 대신 현실적인 여러 단계의 사용자 여정을 사용하세요. Immich를 위한 현실적인 부하 테스트 워크로드는 사진 서버 용량의 대용품으로 반복적인 로그인 요청을 사용하는 대신 가정에서 실제로 수행하는 동작을 혼합해야 합니다.

캐시, 대기열, 데이터베이스 연결, 스토리지 수요가 안정될 수 있도록 각 단계를 충분히 오래 유지하세요. 최대치와 부하를 제거했을 때 시스템이 복구되는지도 모두 기록하세요. 짧은 순간에는 괜찮아 보이지만 계속 증가하는 작업 대기열을 남기는 서버는 해당 워크로드에 대해 이미 지속 가능한 수준을 넘어선 것입니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

가장 먼저 포화되는 리소스를 파악하세요

지연 시간이 급증하면 해당 시각을 리소스 동작과 대조하세요. 검색 또는 머신러닝 중 CPU가 포화된다면 연산 부담을 의미할 수 있습니다. CPU 사용률은 낮은데 디스크 지연 시간이 높다면 데이터베이스 또는 미디어 스토리지가 원인일 수 있습니다. 네트워크 링크가 가득 차면 전송 또는 원격 액세스 한계를 가리키며, 데이터베이스 대기 또는 연결 압력이 증가하면 데이터 계층에 문제가 있을 수 있습니다.

백그라운드 작업은 결과를 바꿀 수 있습니다. 썸네일 생성, 트랜스코딩, 머신러닝, 스캔, 백업 또는 재시도 루프가 아무도 적극적으로 둘러보지 않을 때에도 리소스를 소비할 수 있기 때문입니다. Immich 백그라운드 부하 조건을 통제한 상태에서 테스트와 비교하여, 예약된 작업을 낮은 사용자 한도로 잘못 판단하지 않도록 하세요.

클라이언트 시간 초과 시간을 늘려 오류를 숨기는 방식으로 용량 문제를 “해결”하지 마세요. 제한 리소스 또는 워크로드 정책을 변경하세요. 예를 들어 무거운 작업을 예약하거나, 스토리지 배치를 개선하거나, 동시 트랜스코딩 수를 줄이거나, 연산 성능을 추가할 수 있습니다. 그런 다음 정확히 실패했던 단계를 다시 실행하여 병목이 이동했거나 사라졌는지 확인하세요.

실용적인 가정용 용량 범위를 정하고 다시 테스트하세요

실용적인 용량은 필요한 모든 사용자 여정이 사전에 작성한 지연 시간 및 오류 한도 안에 머물고, 테스트 후 대기열이 기준선에 가까워지는 방향으로 돌아오며, 호스트가 일반적인 백그라운드 작업을 위한 충분한 여유를 유지하는 가장 높은 테스트 동시성으로 정의하세요. 이를 Immich 전체의 최대치가 아니라 워크로드별 범위로 보고하세요.

비교 가능한 깨끗한 상태에서 경계 단계를 최소 한 번 다시 실행하고, 이전에 성능 저하를 일으킨 동작을 포함하세요. 그런 다음 시스템을 통제되지 않은 대기열 또는 스토리지 압박 상태로 몰아넣지 않을 만큼 짧게 다음 단계까지 테스트하여, 경계가 여전히 동일한 리소스에서 나타나는지 확인하세요.

Immich 주요 업그레이드, 데이터베이스 이전, 스토리지 변경, 하드웨어 변경 또는 라이브러리 크기의 큰 증가 후에는 동일한 테스트를 다시 실행하세요. 용량 수치는 현재 시스템과 워크로드의 특성입니다. 예전 사용자 수를 보관하는 것보다 테스트 절차를 유지하는 편이 더 중요합니다.