Home Assistant는 실제로 무엇을 캐시하며, 어떤 반복 요청이 더 빨라지나요?

“Home Assistant는 두 번째 실행이 더 빠르다”는 여러 메커니즘을 설명할 수 있습니다. 브라우저가 프런트엔드 리소스를 재사용할 수도 있고, 이미 열려 있는 대시보드가 페이지를 다시 구성하는 대신 WebSocket을 통해 실시간 상태를 받을 수도 있으며, 운영 체제가 데이터베이스나 구성 페이지를 메모리에 유지할 수도 있고, 통합이 이미 연결된 연결을 재사용할 수도 있습니다.

이러한 모든 효과를 “Home Assistant 캐시”라고 부르면 속도가 향상되는 지점이 어디인지 알기 어렵습니다. 유용한 모델은 반복되는 요청을 명시한 다음, 두 번째 실행에서 어떤 계층이 작업을 생략할 수 있는지 확인하는 것입니다.

브라우저 캐시는 프런트엔드 리소스를 더 빠르게 로드합니다

JavaScript, 스타일, 아이콘, 사용자 지정 카드 및 기타 프런트엔드 리소스는 브라우저 캐시에 남아 있을 수 있으므로, 페이지를 다시 로드할 때 동일한 리소스를 처음부터 다시 다운로드하거나 구성하지 않아도 됩니다.

Home Assistant의 최신 브라우저 안내에는 사용자 인터페이스가 빠르게 작동하도록 브라우저에 많은 항목을 캐시한다고 명시되어 있습니다. 이 캐시는 업데이트나 사용자 지정 카드 변경 후 오래된 상태가 될 수 있으므로, 제대로 작동하지 않는 UI 문제를 강제 새로 고침으로 해결할 수 있습니다.

이 캐시는 페이지 시작과 렌더링에 영향을 주지만, 실제 기기 제어 속도에는 영향을 주지 않습니다. 캐시를 삭제하는 것은 프런트엔드 테스트이지, 일반적인 서버 성능 초기화가 아닙니다.

열려 있는 대시보드는 실시간 WebSocket 상태 경로를 재사용합니다

프런트엔드가 연결되면 변경될 때마다 전체 스마트 홈 상태를 다시 가져올 필요가 없습니다. WebSocket API를 통해 업데이트와 구독 정보를 받고 관련 인터페이스 구성 요소를 업데이트합니다.

현재 프런트엔드 아키텍처는 프런트엔드가 공유 hass 객체를 통해 핵심 상태를 받고 WebSocket을 통해 추가로 구독한 데이터를 동기화 상태로 유지하는 방식을 설명합니다. 따라서 계속 연결된 벽면 태블릿은 매일 아침 대시보드를 처음 여는 휴대폰과는 반복 요청 경로가 다릅니다.

이러한 재사용을 근거로 클라이언트 수가 선형적으로 확장된다고 해석해서는 안 됩니다. 클라이언트가 하나 더 추가될 때마다 직렬화, 구독, 기록 요청 및 클라이언트 측 렌더링 작업이 늘어날 수 있습니다.

Linux 페이지 캐시는 반복적인 파일 및 데이터베이스 읽기를 빠르게 합니다

일반적인 파일 시스템 읽기는 Linux 페이지 캐시를 거칩니다. 최근 사용한 데이터베이스 페이지, 구성 파일 및 정적 리소스가 메모리에 남아 반복 요청에서 물리적 저장 장치를 다시 읽지 않아도 될 수 있습니다.

최신 Linux 커널 문서는 일반적인 파일 읽기가 페이지 캐시를 채우므로 이후 읽기에서는 더 비용이 큰 저장 장치 액세스를 피할 수 있다고 설명합니다. 따라서 Home Assistant가 해당 쿼리에 대해 특별한 애플리케이션 수준 캐시를 구현하지 않았더라도 반복되는 기록 조회가 메모리의 이점을 얻을 수 있습니다.

이 때문에 재부팅, 캐시 제거 또는 훨씬 더 큰 작업 집합을 거친 후보다 웜 테스트에서 SSD와 HDD의 차이가 작게 보일 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

데이터가 웜 상태라고 해서 underlying 쿼리 비용이 낮아진 것은 아닙니다

기록 요청은 여전히 동일한 논리적 양의 데이터를 스캔하거나 인덱싱할 수 있지만, 필요한 페이지가 마침 메모리에 상주할 수 있습니다. 대시보드는 여전히 동일한 엔터티를 요청하지만 리소스와 연결 상태가 이미 준비되어 있을 수 있습니다.

웜 캐시 성능과 실제 용량을 구분하는 관련 ZimaSpace 벤치마크 가이드는 이러한 운영상의 결과를 보여 줍니다. 캐시는 유용하지만, 용량에 대한 주장은 현실적인 캐시 압박과 지속적인 워크로드에서도 성립해야 합니다.

캐시 적중은 하나의 요청에서 하나의 비용을 제거할 뿐입니다. 경로의 다른 단계에 속하는 CPU, 메모리, 네트워크, 데이터베이스 또는 통합 작업까지 제거하지는 않습니다.

반복되는 요청마다 서로 다른 계층이 웜 상태가 됩니다

• 동일한 대시보드 다시 로드: 브라우저 리소스와 클라이언트 런타임이 웜 상태일 수 있습니다.
• 벽면 태블릿을 계속 열어 둠: WebSocket 상태와 구독이 계속 활성 상태로 유지됩니다.
• 동일한 기록 범위를 반복 조회: 데이터베이스와 파일 시스템 페이지가 메모리에 남아 있을 수 있습니다.
• 동일한 로컬 서비스 호출: 통합 또는 네트워크 연결이 이미 설정되어 있을 수 있습니다.
• 재부팅 후 열기: 이러한 계층 중 여러 개가 동시에 콜드 상태일 수 있습니다.

모든 캐시를 삭제한 뒤 이를 “과학적”이라고 부르는 대신, 사용자의 동작에 해당하는 계층을 측정하세요.

FAQ

브라우저 캐시를 삭제하면 Home Assistant Core가 느려지나요?

주로 프런트엔드 로드 경로가 달라집니다. Core는 동일한 서버 로직을 계속 실행하지만, 브라우저가 리소스를 다시 다운로드하고 구성해야 하므로 첫 번째 인터페이스 로드가 느려질 수 있습니다.

웜 상태의 기록 조회는 벤치마크에 쓸모가 없나요?

아닙니다. 웜 쿼리는 실제 운영 조건을 나타냅니다. 문제는 메모리 압박, 재시작 또는 더 큰 작업 집합으로 동일한 캐시 이점이 사라질 수 있는데도 웜 결과를 유일한 용량 결과로 간주하는 것입니다.