Immich 캐싱: 웜 데이터가 반복 요청을 바꾸는 방식

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

모델, 데이터베이스 페이지, 썸네일, 클라이언트 자산이 이전 로딩 작업을 피할 수 있을 만큼 따뜻한 상태로 유지되면 Immich 요청을 반복할수록 더 빨라집니다.

두 번째 검색이 서버의 처리 용량이 향상되었다는 증거는 아닙니다. 첫 번째 요청이 준비한 데이터를 재사용할 수 있으므로, 의미 있는 테스트를 하려면 어떤 상태가 유지되는지 확인하고 콜드 및 웜 동작을 별도로 보고해야 합니다.

첫 번째 요청은 누락된 상태를 준비하는 비용을 부담합니다

재시작 후 또는 장시간 유휴 상태가 지난 뒤에는 Immich 요청에서 코드 경로, 모델 가중치, 데이터베이스 페이지, 썸네일 파일을 활성 메모리로 불러와야 할 수 있습니다. 연결 설정과 클라이언트 자산 검색이 실행될 수도 있습니다. 이후 요청은 표시되는 쿼리가 동일하더라도 이 작업의 일부를 건너뜁니다.

사용자 보고에 따르면 첫 스마트 검색에는 약 5초, 즉시 반복한 검색에는 약 0.5초가 걸렸으며, 모델이 로드되는 동안 GPU 메모리가 증가했습니다. 수치는 구성에 따라 달라지지만, 관찰된 순서는 첫 검색과 반복 검색이 서로 다른 시스템 상태를 나타내는 이유를 보여 줍니다.

정확한 콜드 조건을 기록하세요. 전체 컨테이너 재시작, 머신 러닝 서비스 재시작, 클라이언트 상태 초기화, 또는 정의된 유휴 시간이 그 예입니다. 이러한 조건은 서로 바꿔 사용할 수 없습니다. 단순히 “콜드”라고만 표시된 결과로는 지연이 모델 상주, 서버 페이지 캐시, 연결 설정, 클라이언트 측 재사용 중 어디에서 발생했는지 알 수 없습니다.

웜 상태는 여러 독립 계층에 존재합니다

반복되는 모든 요청을 설명하는 단일 Immich 캐시 스위치는 없습니다. 운영 체제는 파일 페이지를 유지할 수 있고, PostgreSQL은 자주 사용되는 데이터를 재사용할 수 있으며, 머신 러닝 프로세스는 로드된 모델을 유지할 수 있습니다. 브라우저나 모바일 앱은 썸네일과 애플리케이션 자산을 재사용할 수 있습니다. 각 계층의 수명은 서로 다릅니다.

캐시 워밍 개요에서는 일반적인 차이를 설명합니다. 웜 캐시는 보관된 데이터를 더 짧은 지연으로 제공하지만, 콜드 캐시는 더 느린 기본 소스에서 가져와야 합니다. Immich에서 기본 소스는 영구 스토리지일 수 있으며, “데이터”는 미디어, 데이터베이스 페이지 또는 모델 파일일 수 있습니다.

선택적으로 상태를 초기화하세요. 동일한 브라우저에서 반복한 다음 새 클라이언트에서 테스트하고, 머신 러닝 서비스만 재시작한 다음 애플리케이션을 재시작하고, 마지막으로 호스트를 재부팅하세요. 긴 지연을 되살리는 첫 번째 초기화가 유지된 상태 중 가장 큰 영향을 준 계층을 보여 줍니다. 다만 여러 계층의 영향이 누적될 수도 있습니다.

웜 결과는 용량 한계를 숨길 수 있습니다

반복 검색을 소수만 수행하면 정확히 필요한 페이지와 썸네일만 상주 상태로 유지할 수 있습니다. 이 벤치마크는 훌륭해 보일 수 있지만, 더 큰 가족 라이브러리가 메모리를 초과하면 캐시 미스가 자주 발생합니다. 작업 집합이 바뀌거나 다른 서비스가 데이터를 내보내거나 재시작으로 임시 상태가 사라질 때 용량 한계가 드러납니다.

ZimaSpace의 데이터 경로 설명은 데이터베이스 선택과 미디어 표시를 구분합니다. 따라서 웜 상태의 썸네일이 느린 쿼리를 가리거나, 캐시된 쿼리가 느린 파일 전송을 가리는 일을 방지할 수 있습니다. 반복 요청으로 인한 향상을 진단할 때는 결과 식별자와 표시되는 자산의 시간을 각각 측정하세요.

하나의 항목만 계속 반복하지 말고 여러 쿼리와 타임라인 구간을 번갈아 사용하세요. 대표적인 유휴 시간과 경쟁 작업도 포함하세요. 서버에 유용한 용량이 있다는 것은 하나의 핫 경로만 상주 상태로 유지될 때가 아니라, 예상되는 작업 집합 전반에서 허용 가능한 지연 시간이 지속될 때를 의미합니다.

콜드, 웜, 교란된 실행을 함께 보고하세요

세 부분으로 구성된 프로토콜을 만드세요. 먼저 문서화된 콜드 조건에서 엔드포인트를 실행합니다. 다음으로 입력을 변경하지 않고 즉시 반복합니다. 세 번째로 예상되는 교란 요소인 유휴 시간, 다른 컨테이너 또는 더 넓은 쿼리 집합을 적용한 뒤 다시 실행합니다. 단일 스톱워치 값이 아니라 중앙값과 지연 시간의 느린 꼬리를 기록하세요.

첫 검색 지원 스레드에서는 최초 지연이 10~15초였고 이후 반복 검색은 거의 즉시 완료되었다고 보고합니다. 이는 두 분포를 모두 보존해야 할 필요성을 뒷받침합니다. 이 사례가 보편적인 Immich 실행 시간을 확립하는 것은 아닙니다. 모델 선택, 가속기, 메모리, 스토리지, 릴리스에 따라 그 격차는 달라질 수 있습니다.

결론에는 두 개의 수치와 하나의 경계를 제시하세요. 일반적인 웜 지연 시간, 일반적인 콜드 지연 시간, 그리고 웜 상태를 잃게 만드는 사건입니다. 콜드 동작이 가정의 목표를 충족하지 못한다면 필요한 상태를 상주시키거나 해당 로딩 경로를 개선하세요. 인위적인 콜드 테스트에서만 실패한다면 허용되는 운영 조건으로 문서화하세요.

기술 및 AI 허브

더 읽어보기

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.