반복 가능한 Immich 벤치마크는 한 가지 변수를 변경하기 전에 미디어 집합, 클라이언트 경로, 캐시 상태, 백그라운드 작업 중첩, 측정 엔드포인트를 고정합니다.
이러한 통제가 없으면 두 번째 실행이 더 빠른 이유가 하드웨어 개선이 아니라 데이터가 캐시에 올라왔기 때문일 수 있으며, 유휴 상태 테스트는 가져오기 중 경합을 숨길 수 있습니다. 유용한 홈 서버 벤치마크는 가정에서 실제로 발생하는 탐색, 업로드, 검색, 복구 요구를 동일한 순서로 재현합니다.
메트릭을 수집하기 전에 사용자 결과를 정의하세요
업로드 수락, 새 사진을 검색할 수 있을 때까지의 시간, 타임라인 썸네일 완성, 원본 열기, 동영상 재생 시작 또는 사용 가능한 라이브러리로 복구하는 시간처럼 관찰 가능한 결과부터 정하세요. CPU 사용률과 디스크 처리량은 이러한 결과를 설명하지만, 사용자에게 보이는 결과를 대신할 수는 없습니다.
ZimaSpace의 Immich 데이터 경로 문서는 업로드 수락, 처리 준비 완료, 검색 선택, 미디어 전달을 구분합니다. 이 구조가 유용한 이유는 벤치마크가 여러 종속 단계를 오해의 소지가 있는 총합으로 섞지 않고 하나의 엔드포인트를 측정해야 하기 때문입니다.
대화형 엔드포인트 두 개와 백그라운드 엔드포인트 하나를 선택하세요. 각각에 통과 기준을 정하고 중앙값과 지연 시간의 느린 꼬리 또는 완료율을 기록하세요. 서로 관련 없는 점수가 너무 많은 벤치마크는 해석하기 어려워집니다. 특정 의사 결정과 연결된 소수의 지표로 구성하면 결과를 실행에 옮기기 쉽습니다.
데이터 세트, 클라이언트 경로, 시작 상태를 고정하세요
가족 라이브러리와 일치하는 형식과 크기를 포함해 모든 실행에서 동일한 대표 사진과 동영상을 사용하세요. 계정, 클라이언트 기기, 네트워크 경로, Immich 버전, 파생 파일 설정을 고정하세요. 브라우저 캐시나 Wi-Fi 경로만 바뀌어도 테스트 중인 구성 차이를 압도할 수 있습니다.
벡터 검색 벤치마킹 문서는 PostgreSQL 검색 성능을 연구할 때 임베딩, 삽입, 검색 작업을 반복 가능하게 설정하는 것이 중요하다고 강조합니다. Immich는 더 광범위한 애플리케이션이지만 실험 원칙은 동일하게 적용됩니다. 시간 차이가 결론을 뒷받침하려면 통제된 입력과 정의된 검색 작업이 먼저 필요합니다.
파일 체크섬, 개수, 총 바이트 수, 사진 형식, 동영상 길이, 예상 검색 결과가 포함된 데이터 세트 매니페스트를 만드세요. 재시작한 서비스, 워밍업 작업, 대기 중인 작업, 경쟁 애플리케이션을 확인하는 시작 체크리스트도 추가하세요. 체크리스트가 다르면 평균에 포함하지 말고 해당 실행을 비교 불가로 표시하세요.
콜드, 웜, 지속 단계로 실행하세요
콜드 단계에서는 초기화 및 최초 접근 비용이 드러납니다. 웜 단계에서는 즉시 반복할 때의 재사용 효과가 드러납니다. 지속 단계에서는 대표적인 가져오기 또는 백그라운드 대기열과 반복 상호 작용을 충분히 오래 섞어 열 스로틀링, 메모리 압박, 스토리지 대기열, 리소스 경합을 드러냅니다.
한 커뮤니티 보고서에서는 첫 번째 스마트 검색에 약 5초가 걸리고 모델 메모리 상태가 바뀌는 동안 즉시 반복한 검색은 약 0.5초가 걸렸다고 설명합니다. 이 수치들은 벤치마크 표준이 아닙니다. 콜드 요청과 웜 요청의 평균을 내면 테스트가 설명해야 할 전환이 가려지는 이유를 보여주는 사례입니다.
각 단계를 최소 세 번 실행하면서 원시 타임스탬프와 리소스 추적 정보를 보존하세요. 대화형 작업에는 중앙값과 느린 꼬리 측정값을, 백그라운드 작업에는 분당 대기열 처리 항목 수를 유지하세요. 오류, 스왑 폭주 또는 열 제한으로 의도한 정상 상태가 무효화되면 실행을 중단하세요.
한 가지 변수만 변경하는 실행 시트를 사용하세요
실행 전에 가설을 작성하세요. 데이터베이스 배치, 작업자 동시성, 메모리 제한, 네트워크 경로 또는 가속기를 변경하면 하나의 명시된 메커니즘을 통해 지정한 엔드포인트 하나가 개선되어야 합니다. 나머지는 모두 고정하세요. 이렇게 해야 여러 가지를 동시에 업그레이드한 뒤 결과가 빨라져도 원인을 방어 가능하게 설명할 수 없는 상황을 피할 수 있습니다.
일반적인 병목 현상 분석에서는 CPU, RAM, 스토리지, 네트워크 한계가 서로 다른 사용률 패턴과 사용자 영향을 만든다고 설명합니다. 이를 Immich에 적용하면 보조 메트릭도 엔드포인트와 일관되게 움직여야 합니다. 가장 바쁜 차트가 자동으로 제한 요소인 것은 아닙니다.
콜드, 웜, 지속 단계에서 기준 결과와 변경 결과를 기록한 다음 통과, 실패 또는 결론 보류로 표시하세요. 반복 실행에서 사라지거나 오류, 불안정한 온도, 대기열 진행 손실 또는 더 긴 복구 시간을 유발하는 개선은 거부하세요. 향후 릴리스와 정직하게 비교할 수 있도록 매니페스트와 실행 시트를 보존하세요.
기술 및 AI 허브
더 읽어보기

업그레이드 후 Immich가 기존 데이터를 다시 처리하는 이유는 무엇인가요?
업그레이드로 인해 이전 파생 파일, 메타데이터, 모델 또는 작업 상태가 무효화되면 Immich가 에셋을 다시 처리할 수 있습니다. 반복적으로 작업이 끝없이 실행되는 것은 별도의 문제입니다.

실제 Immich 성능의 한계를 가장 자주 결정하는 종속 요소는 무엇인가?
Immich는 측정된 각 경로에서 가장 느린 종속 요소에 의해 성능 상한이 결정되므로, 업로드·검색·탐색·재생의 성능 한계가 서로 다를 수 있습니다.

Immich 네트워킹: 검색, DNS, 라우팅이 연결 가능성을 만드는 방식
엔드포인트 선택, DNS, 라우팅, NAT 또는 프록시 처리, TLS, 애플리케이션 응답이 하나의 유효한 경로를 구성할 때만 Immich에 연결할 수 있습니다.

