용량을 캐시로 착각하지 않고 Immich 성능을 측정하는 방법

Immich 용량은 반복적인 콜드, 웜, 지속 부하를 통해 측정해야 합니다. 빠른 캐시 실행 한 번으로는 시스템의 실제 포화 지점을 가릴 수 있기 때문입니다.

홈 서버에서는 동일한 썸네일, 데이터베이스 페이지, 애플리케이션 데이터에 이미 접근한 뒤 타임라인이나 앨범이 매우 빠르게 느껴질 수 있습니다. 이 결과는 웜 경로가 효율적이라는 점을 보여줄 뿐, 시스템이 더 큰 가족 라이브러리나 더 많은 동시 활동을 지속적으로 처리할 수 있다는 뜻은 아닙니다. 유용한 용량 테스트를 위해서는 캐시 상태를 통제하고, 작업 집합을 확대하며, 테스트를 반복하고, 측정 가능한 중단 조건을 정의해야 합니다.

캐시 속도는 용량과 같지 않습니다

용량은 지연 시간, 대기열 또는 오류가 허용하기 어려운 수준에 도달하기 전까지 Immich 시스템이 지속적으로 처리할 수 있는 대표 작업의 양을 의미합니다. 캐시 속도는 유용한 데이터나 생성된 자산이 이미 가까이에 있는 상태에서 시스템이 작업을 얼마나 빠르게 반복할 수 있는지를 묻는 더 좁은 개념입니다. 벤치마크가 동일한 앨범이나 타임라인을 반복하면 서로 다른 운영 조건을 측정하면서도 이 두 질문이 같은 것처럼 보일 수 있습니다.

이 차이는 웹 성능에서 쉽게 확인할 수 있습니다. 이후 요청이 캐시된 리소스를 재사용하기 때문에 첫 조회와 반복 조회 시간은 크게 달라질 수 있습니다. Immich에서는 썸네일, 미리보기, 데이터베이스 페이지, 파일 시스템 메타데이터, 운영 체제 캐시, 클라이언트 자산이 모두 재사용될 수 있어 웜 동작이 나타날 기회가 더 많습니다. 따라서 반복 실행에서는 라이브러리가 커지거나 새로 접근될 때 여전히 필요한 작업이 제거될 수 있습니다.

반복 요청이 표본의 대부분을 차지할 때 캐시 중심의 Home Assistant 테스트가 오해를 불러올 수 있는 이유도 같습니다. ZimaSpace에서 설명하는 반복 요청 캐시 계층의 논리는 여기서도 적용됩니다. Immich에서는 웜 성능을 기록하되, 이를 서버의 일반적인 용량으로 간주하지 말고 별도의 경로로 표시해야 합니다.

콜드, 웜, 정상 상태 실행을 분리하세요

스톱워치를 누르기 전에 먼저 상태를 정의하세요. 콜드 실행에는 방금 반복하지 않은 작업이 포함되어야 합니다. 예를 들어 캐시가 도움을 줄 기회가 적은 다른 날짜 범위나 자산 집합을 여는 방식입니다. 웜 실행에서는 의도적으로 이미 알고 있는 경로를 반복합니다. 정상 상태 실행에서는 대표적인 활동을 충분히 오래 지속해 짧은 폭주에서는 드러나지 않을 백그라운드 작업, 리소스 재활용, 대기열을 노출시켜야 합니다.

웜업 자체도 오해를 불러올 수 있습니다. Percona는 지연된 백그라운드 프로세스가 성능을 계속 바꾸는 동안 데이터베이스가 이미 웜 상태인 것처럼 보이는 사례를 설명합니다. 따라서 정상 상태는 첫 번째 빠른 쿼리보다 늦게 도달할 수 있습니다. Immich에서도 당시 라이브러리 작업에 따라 포그라운드 탐색이 데이터베이스 활동, 썸네일 작업, 인덱싱 또는 기타 대기 중인 작업과 겹칠 수 있습니다.

홈 서버 테스트에서는 각 단계를 함께 평균 내지 말고 별도로 실행하세요. 백그라운드 작업이 유휴 상태인지 활성 상태인지 기록하고, 클라이언트와 네트워크 경로를 일정하게 유지하며, 동일한 단계를 여러 번 반복하세요. 웜 실행은 빠르지만 지속적인 활동으로 지연 시간이나 대기열 깊이가 점차 증가한다면, 용량 계획에는 두 번째 결과가 더 유용한 신호입니다.

작업 집합을 쉽게 캐시되는 범위보다 크게 만드세요

동일한 사진 스무 장만 여는 벤치마크는 일반적인 가족 라이브러리의 용량을 판단하기에 대체로 너무 작습니다. 운영 체제, 데이터베이스, 클라이언트, 스토리지 스택이 작은 핫 세트를 프로세서 가까이에 유지할 수 있지만, 실제 사용에서는 여러 달, 사람, 앨범, 검색 결과, 동영상 사이를 오갑니다. 따라서 테스트 세트는 모든 작업이 최근에 접근한 동일한 데이터의 이점을 누리지 않도록 충분히 크고 다양해야 합니다.

데이터베이스 벤치마킹 관행은 이 차이를 분명히 보여줍니다. 테스트 목적이 스토리지나 콜드 동작을 확인하는 것인데 잔여 캐시가 남아 있으면, 테스트가 대신 캐시 성능을 측정하게 될 수 있습니다. 프로덕션 Immich 서버의 모든 캐시 계층을 삭제할 필요는 없지만, 반복해서 재사용하는 화면 하나보다 작업 집합이 더 넓은 워크로드를 사용해야 유용한 결과를 얻을 수 있습니다.

일반적인 가정 내 사용을 반영하는 여러 날짜 범위, 앨범, 검색, 자산 유형을 선택한 뒤 한 화면만 집중적으로 사용하는 대신 순환하며 실행하세요. 하드웨어나 설정을 비교할 때는 이 워크로드 정의를 유지해야 합니다. 변경 사항이 작고 반복적인 일부만 개선하고 부하가 걸렸을 때 더 넓은 탐색이 계속 느려진다면, 핫 경로는 개선했지만 유용한 용량의 한계는 높이지 못한 것입니다.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

백분위수를 측정하고 테스트를 반복하세요

평균 하나만으로는 사용자가 실제로 체감하는 순간을 가릴 수 있습니다. 요청 9개는 빠르고 10번째 요청은 대기열이 쌓이거나 스토리지가 바쁜 동안 멈추더라도 평균은 여전히 양호해 보일 수 있습니다. 최소한 중앙값과 p95 같은 꼬리 백분위수 하나를 기록하고, 지연 시간과 함께 처리량, 오류 수, 작업 백로그, CPU, 메모리 압박, 스토리지 활동을 측정해 지연의 맥락을 파악하세요.

실용적인 벤치마크 분석에서는 특히 캐시 축출, 컴팩션 또는 백그라운드 활동이 나중에 나타날 수 있는 상태 기반 시스템에서 단일 실행을 신뢰하기보다 p50, p95, p99와 분산을 보고할 것을 권장합니다. Immich 테스트에 실험실 수준의 정밀도는 필요하지 않지만, 반복 가능한 한계와 우연히 조용했던 구간을 구분할 수 있을 만큼 충분히 반복해야 합니다.

각 부하 수준에서 동일한 시나리오를 최소 여러 번 실행하고, 가장 좋은 결과만 남기지 말고 원시 관측값을 보관하세요. p95가 여러 실행에서 안정적으로 유지되고 서버가 각 측정 구간 사이에 대기 중인 작업을 처리한다면 용량 주장의 신뢰도가 높아집니다. 결과의 변동이 크다면 사용자 수 증가, 사진 증가 또는 더 빠른 하드웨어가 한계를 바꿨다고 결론 내리기 전에 통제되지 않은 변수를 조사하세요.

중단 조건이 있는 Immich 용량 프로토콜을 사용하세요

대표적인 클라이언트 워크로드 하나로 시작하고, 테스트하려는 상태에 시스템이 도달한 후 기준선을 측정하세요. 그런 다음 한 번에 하나의 변수만 늘리세요. 라이브러리, 클라이언트 구성, 네트워크 경로, 서버 설정은 고정한 채 동시 탐색, 업로드, 검색 또는 백그라운드 처리를 늘리는 방식입니다. 각 단계에서 p50 및 p95 지연 시간, 분당 성공 작업 수, 오류, 대기열 증가, 포화에 가까워지는 주요 서버 리소스를 기록하세요.

이 방법은 짧은 실행 한 번으로 결론을 내리는 흔한 실수를 피하게 해줍니다. 성능 테스트 지침은 웜업, 캐시 상태, 백그라운드 작업, 일반적인 시스템 잡음이 표본을 좌우할 수 있으므로 단일 실행에 기반한 결론을 경고합니다. 각 부하 수준을 충분히 반복해 단순히 인용하기 편한 정도가 아니라 설명할 수 있을 만큼 추세가 안정되도록 하세요.

테스트 전에 중단 규칙을 선언하세요. 실용적인 홈 랩 경험칙으로는 p95 지연 시간이 유휴 상태 기준선의 약 2배를 초과한 상태가 3개의 연속 측정 구간 동안 유지되거나, 오류 또는 작업 백로그가 회복되지 않고 계속 증가할 때 현재 설정이 포화된 것으로 간주할 수 있습니다. 이는 테스트용 경험칙이며 Immich의 제한값은 아닙니다. 유용한 용량 수치는 동일한 콜드, 웜, 정상 상태 프로토콜로 측정했을 때 해당 경계보다 낮은 마지막 부하 수준입니다.