캐싱 XML 응답

우리는 Call-Center의 주문 시스템에이 API를 가지고 온라인 주문이 통신합니다. 하지만 많은 요청과 응답은 동일하거나 다소 정적입니다.하지만 API 서버가 생성하므로 정적 파일 만 제공하는 것이 아닙니다.캐싱 XML 응답

XML 응답을 캐싱하기위한 최선의 방법으로 무엇을 제안합니까? Zend_Cache를 살펴 보았습니다. 하지만 내가 이해하는 바에 따르면, 클라이언트/세션 기반이라고 생각합니다. 모든 클라이언트가 동일한 캐시를 활용할 수 있기를 바랍니다.

또한 모든 페이지 뷰는 바구니의 내용에 대해 가격을 결정합니다. 어떤 캐싱을 권장합니까? 나는 Zend_Cache가 아마도 여기에 참가할 수있을 것이라고 생각한다.

기본적으로 API 서버의로드가 필요하므로 가격 요청을 처리하는 데 더 많은 리소스가 필요하며 요청 당 변경되는 다른 요청이 있습니다.

업데이트 : 13 2010년 12월 10.45

요청 타이밍

2010-12-10T14:43:46+01:00 DEBUG (7): XML GET /ccstatus [0.054742097854614] 
2010-12-10T14:43:46+01:00 DEBUG (7): XML GET /storestatus [0.063634157180786] 
2010-12-10T14:43:46+01:00 DEBUG (7): XML GET /storestatus [0.062693119049072] 
2010-12-10T14:43:46+01:00 DEBUG (7): XML GET /storestatus [0.062756061553955] 
2010-12-10T14:43:46+01:00 DEBUG (7): XML GET /storestatus [0.062740087509155] 
2010-12-10T14:43:46+01:00 DEBUG (7): XML GET /storelocations [0.065214872360229] 
2010-12-10T14:43:46+01:00 DEBUG (7): XML GET /coupons [0.070861101150513] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /packagedeals [0.51115489006042] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML POST /price [0.065691947937012] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /pizzas [0.10685706138611] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /bevtypes [0.059874057769775] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /bevsizes [0.056848049163818] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /items [0.070401191711426] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /storestatus [0.062546014785767] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /storestatus [0.063254117965698] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /storestatus [0.062647104263306] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /storestatus [0.062632083892822] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /storestatus [0.062486886978149] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /items [0.059072017669678] 
2010-12-10T14:43:47+01:00 DEBUG (7): XML GET /storestatus [0.062618970870972] 
2010-12-10T14:43:48+01:00 DEBUG (7): XML POST /price [0.063409805297852]

이 측면 주문의 페이지를 보여주는 하나의 페이지 뷰에 대한 요청, 그리고 바구니 두 항목이 포함되어 있습니다.

이 시간을 기준으로 데이터를 캐싱하여 상당한 차이가 있다고 생각합니까? 이 시간은 전혀로드되지 않으므로로드가 많으면 캐싱이 편리 할 수 있습니다.

출처

2010-12-10 Phliplip

바구니 의존적 인 pricerequest 요청에 대해 많은 캐싱을 수행하지는 않습니다. 세션 기반, 매우 가변적이기 때문에 이러한 요청은 당연히 필요할 것 같습니다.

다른 요청 - "API 요청"- 사용자가 제안한 것처럼 정적 인 경우 File 또는 Memcached 백엔드가있는 Zend_Cache를 곧바로 사용할 수있는 훌륭한 후보로 보입니다. 캐싱 할 정적 API 요청마다 고유 한 키를 생성하는 알고리즘을 찾아야합니다.

프론트 엔드 옵션에서 무한 수명을 지정하고 컨텐츠를 최신으로 유지하기에 충분하다고 생각되는 빈도로 캐시를 다시 채우기 위해 cron 작업을 실행할 수도 있습니다.

큰소리로 생각해보십시오.

건배!

출처

2010-12-10 15:51:29

Great thoughts :) 가격 요청에 대해 세션의 마지막 응답을 저장하려고 생각하고 변경 사항이있을 경우에만 응답을 업데이트/새로 고침합니다. 바스켓의 내용 하지만 아마 맞을 것입니다. 아마도 파일에 다소 정적 인 요청을 저장할 수 있습니다. 각 요청이 API에서 가져 오는 로그의 목록을 가진 초기 게시물을 업데이트했습니다. – Phliplip

바스켓이 변경되지 않은 경우 새로운 pricerequest를 수행 할 필요가 없습니다. 좋은 캐치. ;-) –

Zend_Cache 파일과 cron 작업을 사용하여 캐시를 업데이트했기 때문에 대답을 수락했습니다. 우리는 즉시 온라인 주문에서로드 시간이 50 % 감소한 것을 보았습니다 :) 과학적 방법은 없습니다. 페이지가로드 될 때까지 몇 초의 링크를 클릭하기 만하면됩니다. – Phliplip

Zend_Cache은 세션 기반이 아닙니다. 그것에는 number of backends to store the cached data in이 있습니다. 예를 들어 네트워크에 memcached 서버를 설치하고 거기에 XML을 저장할 수 있습니다. 함수 호출이나 전체 페이지 결과 또는 임의의 키를 사용하여 캐시 할 수 있습니다.

당신은 투명하게 API 서버에 대한 요청을 처리하고 캐시 된 응답 또는 쿼리를 제공할지 여부를 결정하여 API 서버와 클라이언트 사이의 캐싱 프록시를 추가하는 것입니다 articles about Zend_Cache at Devzone

또 다른 옵션의 번호를 찾을 수 있습니다

API 서버 이 접근법의 장점은 캐싱 로직을 API 서버로부터 멀리 유지한다는 것입니다. 단점은 다른 서버가 필요하다는 것입니다.

출처

2010-12-10 09:56:43 Gordon

고려해야 할 프록시는 Varnish (http://www.varnish-cache.org/)와 Squid (http://www.squid-cache.org/)입니다. – ivy

다른 서버 * 응용 프로그램 *하지만 반드시 다른 물리적 서버 *는 아닙니다. –

@ 엘 요보 나는 어떤 말을하지 않았는가? ;) – Gordon

캐싱 XML 응답

답변

관련 문제