Ajax "캐싱", 좋음, 나쁨, 무관심한가요?

그래서 저는 GET 메서드를 사용하여 Ajax 요청을 브라우저 캐싱하는 것을 의미하지는 않지만 브라우저의 메모리에 대형 쿼리 (40- 300kb 쿼리의 두 자리 숫자)를 저장하는 것을 의미하지는 않습니다.Ajax "캐싱", 좋음, 나쁨, 무관심한가요?

보이지 않는 이점, 위험이 있습니까?

var response = JSON.parse(xhr.responseText); 
Cache.push(response); // Store parsed JSON object in global variable `Cache` 
// Time passes, stuff is done ... 
if(Cache[query]) 
    load(Cache[query]) 
else 
    Ajax(query, cache_results);

출처

2009-12-30 Tom

실제로 필요한가요? 아니면 그냥 최적화를 위해서입니까? 먼저 프로파일 링을 수행하고 병목 현상이있는 곳을 확인하는 것이 좋습니다. 웹 페이지 세션은 일반적으로 오래 지속되지 않으므로 오프라인 저장 장치를 사용하지 않는 한 캐시는 오래 지속되지 않습니다.

출처

2009-12-30 02:05:19 mkrause

는 말하기 어렵다 시스템의 전체보기를 가지고 있지하지만 잠재적으로 오래된 데이터를 재생하는 것은 문제가 될 것이라고 생각합니다.

"캐시 신선도"를 해결할 수있는 프로토콜을 가지고 있다면 당연히 바른 길에 있습니다 .... 그렇다면 왜 HTTP 프로토콜을 사용하지 않을까요? (HTTP GET ETag/Last-Modified 헤더로)

출처

2009-12-30 02:04:45 jldupont

많은 300kb 문자열을 저장할 때 메모리 사용과 다양한 브라우저의 일반적인 성능을 스트레스 테스트하고 싶을 것입니다. 작업 관리자에서 모니터링하고 Speed Tracer 및 dynatrace ajax edition과 같은 성능 도구를 사용할 수도 있습니다.

캐싱이 성능면에서는 좋지만 메모리에 문자열이 너무 많으면 속도가 느려지므로 HTML5 저장소 나 플래시 저장소를 사용하여 문자열을 저장할 수 있습니다. 세션 전반에 걸쳐 항목을 캐시합니다. Dojo storage은 이에 대한 좋은 라이브러리입니다.

출처

2009-12-30 02:06:39 Annie

Ajax "캐싱", 좋음, 나쁨, 무관심한가요?

답변

관련 문제