0
캘린더/일정 웹 응용 프로그램에 대한 캐싱 데이터와 관련하여 질문이 있습니다. 좋은 반응이 있습니다. 그러나, 나는 자바 스크립트에서 데이터를 캐싱하고 내 접근 방식을 변경하기로 결정했다.javascript 및 asp.net 캐싱 문제
$ ('body'). data() 객체의 캘린더 그리드에서 매일 열에 대해 HTML을 직접 캐싱하고있어 매우 빠른 페이지로드 시간 (거의 눈에 띄지 않음)을 제공합니다.
그러나 사용자가 아직 캐시에없는 데이터를 요청할 때 문제가 발생하기 시작합니다. 이 데이터는 서버가 ajax 호출을 사용하여 생성하므로 비동기식이며 주당 약 0.2 초의 데이터가 필요합니다.
현재 사용자가 서버에서 정보를 요청할 때 0.5 초를 차단하고 페이지 당 4 주 또는 페이지 변경 요청 (페이지 변경 요청 당 1 주일 추가)을 캐시하면되지만 이것이 의심 스럽습니다. 최적의 방법.
상황을 개선하는 방법에 대한 제안 사항이 있습니까?
은 요약하면 : 이- 매주 서버에서 검색하는 데 0.2 초 소요, 비동기.
- 성능은 가능한 한 실시간에 가깝습니다. (그러나 데이터가 완전히 실시간 일 필요는 없습니다. 대부분의 약속은 사용자가 추가하므로 이후에 다시 캐시 할 수 있습니다.)
- 로드 중 한 주일에 현재 4 주가 캐싱됩니다. 부족한.
- 캐시에 1 년 ~ 21 초가 소요됩니다. 초기로드에는 너무 느립니다.
이것은 OT 일 수 있으며 어떤 식 으로든 유치하지 않습니다. 서버 측 시간에 대해 할 수있는 일이 있습니까? 나는 당신이 ~ 0.2 초 후에 한 주를 얻는다는 것에 놀랐지 만, 2 주는 ~ 0.4 초가 걸린다. 나는 대부분의 백엔드에서 2 주간에 거의 정확히 1 주일 정도의 시간이 걸릴 것이라고 예상 했었을 것이다. 그 시간의 대부분은 요청을 설정하고, DB 풀이나 기타 등에서 연결을 확인하는 것이 었습니다. 실제 쿼리 그러나 다시 이것은 아마도 구약이고 아마도 당신의 인프라를 모른다는 것을 근거로합니다. :-) –
예, 저는 서버에서 수행중인 작업에 대해 더 많은 정보가 필요하다고 생각합니다. 당신의 감속은 어디입니까? 일반적으로 그것은 DB에 있지만, 물론 그것은 다른 것입니다. – WVDominick
아니요, 공정한 의견입니다. 실제로 전송 시간을 가져 왔습니다. (포함 된 경우 0.5에 가까워졌습니다.) 전송 속도를 고려하지 않았습니다. 이것은 로컬 ASP.net dev 환경에서 실행 중입니다. 디버그)가 필요합니다. 라이브 서버에 연결되면 라이브 설정이로드 균형을 유지하기 때문에 동일하게 유지된다는 보장이 없으므로 라우팅 등으로 인해 성능이 변할 수 있습니다. 1 년 동안 20 %의 수치 포함 된 송금입니다. 1 주일에 데이터 소스에서 HTML로 전환하는 데 ~ 0.2 초가 걸린다는 점을 더 많이 생각할 것입니다. –