몇 분마다 장치에서 메시지를받는 응용 프로그램이 있습니다. 특정 장치에 대한 마지막 10 개의 메시지를 요청하는 클라이언트도 있습니다.데이터를 선점해야합니까?
나는 데이터베이스 포화 상태에 시달리고 있으며 장치별로이 목록을 캐시하고 싶습니다. 기본 전제는 메시지가 장치에서 수신되면 메시지를 수신하는 프로세서는 해당 장치의 캐시를 무효화합니다.
제 질문은 캐시를 무효화하고 다음 클라이언트가 연결될 때 캐시를 다시 만들어야하는지, 아니면 장치 프로세서가 캐시를 선제 적으로 다시 작성해야하는지 여부입니다. 장치 프로세서는 현재 캐시를 검색하여 마지막 항목을 끈 다음 새 항목을 추가하고 새 결과를 캐시 할 수 있습니다.
감사합니다.이 질문에 대한 답변이 다를 수도 있습니다. 답변 :이 분야에 대한 사람들의 경험을 듣고 감사하게 생각합니다.
나는 당신이 "pre-fetch"메커니즘을 설명하고 있다고 생각한다. :)
이 분야에서는 많은 경험이 없지만 데이터를 미리 가져 와서 클라이언트가 원하는대로 안정적으로 예측할 수 있다고 믿으면 측정 가능하고 바람직한 성능 향상을 얻을 수 있습니다. 그것 때문에, 그 다음에 가서 소용돌이 치십시오.
캐싱의 모든 털이를 염두에 두십시오. 기본 데이터가 바뀌면 어떻게 무효화됩니까? 행운을 빌어 요!
내가 들었지만 실제로 의존합니다. 많은 변수에서.
나라면 캐시를 무효화하고 다음 클라이언트가 약간 더 단순 해 보이기 때문에 캐시를 다시 만들어 보도록 하겠지만 두 방법을 모두 시도하지 않고 어느 방법이 더 효과적인지 결정할 수는 없습니다.
클라이언트 서버를 과도하게 시뮬레이션하여 실제 서버를 망칠 필요가 없기를 바랍니다.
평균적으로 클라이언트가 주어진 장치에 대해 메시지를 검색하는 횟수를 정량화 할 때까지는이 질문에 대답 할 수 없다고 생각합니다. 파란색 달에 한 번만 특정 장치에 대한 메시지가 쿼리 된 경우 각 클라이언트 요청에서 메시지 캐시를 제거하는 것이 좋습니다. 그러나 주어진 장치의 메시지 큐가 여러 번 쿼리되는 경우 장치 동기화에 선점 형 캐싱이 가장 좋은 옵션 일 수 있습니다. 장치 동기화가 덜한 경우 클라이언트 요청입니다.
로드에 따라 적응 적으로 캐시하는 시스템을 작성하는 것이 가장 좋습니다. 주어진 장치의 메시지 큐가 자주 쿼리되면 장치 동기화시 캐시를 새로 고칩니다. 장치 메시지 큐가 거의 쿼리되지 않으면 클라이언트 요청시 캐시를 새로 고칩니다.
감사하게도 캐시를 무효화하는 이벤트는 새 메시지의 수신 만 있습니다. 이것은 "사소한 변화"가되어야합니다. –