Caching réponses XML

Question

Nous avons cette API à notre système de commande dans notre Call-Center, avec lequel notre commande en ligne communique. Mais beaucoup de demandes et de réponses sont identiques, plus ou moins statiques - mais le serveur API les génère, il ne fournit pas seulement un fichier statique. Que suggérez-vous comme la meilleure approche pour mettre en cache des réponses XML? J'ai jeté un coup d'oeil à Zend_Cache. Mais d'après ce que je comprends, je pense que c'est client/session, je voudrais que tous les clients profitent du même cache.

Chaque pageview fait une demande de prix pour le contenu du panier, quelle mise en cache proposez-vous pour cela. Je pense que Zend_Cache pourrait peut-être entrer en jeu ici? Fondamentalement, ce dont j'ai besoin, c'est de prendre la charge du serveur API, donc il a plus de ressources pour répondre aux demandes de prix, et d'autres demandes qui changent par demande.

Mise à jour: 13. Dec. 2010 10,45

Demande calendrier

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] 

Ce sont les demandes d'un seul PageView, montrant une page de commandes de côté, et le panier contient 2 articles.

En fonction de ces périodes, pensez-vous que je vais obtenir une différence considérable en mettant en cache les données? Ces temps sont sans charge, donc en cas de charge élevée, la mise en cache pourrait probablement être utile.

Answer 1

Je ne vois pas un moyen évident de faire beaucoup de mise en cache sur les demandes de pricerequest qui dépendent du panier. Ceux-ci me semblent probablement basés sur des sessions, très variables, donc le calcul par requête semble assez nécessaire. Les autres demandes - les "requêtes API" - si elles sont vraiment aussi statiques que vous le suggérez, elles semblent être un excellent candidat pour Zend_Cache avec un backend File ou Memcached. Juste besoin de comprendre un algorithme pour générer une clé unique pour chacune des demandes d'API statiques que vous souhaitez mettre en cache.

Vous pouvez même spécifier une durée de vie infinie dans les options de l'interface client et exécuter un travail cron pour repeupler le cache sur la fréquence que vous jugez raisonnable pour maintenir le contenu à jour.

Juste à voix haute.

À la votre!

Answer 2

Zend_Cache n'est pas basé sur une session. Il a un number of backends to store the cached data in. Par exemple, vous pouvez configurer un serveur memcached sur votre réseau et y stocker le XML. Vous pouvez mettre en cache par appel de fonction ou des résultats de page entiers ou par des clés arbitraires.

Vous pouvez trouver plusieurs articles about Zend_Cache at Devzone

Une autre option serait d'ajouter un Caching Proxy entre votre API Server et vos clients qui gère de manière transparente toutes les demandes de votre API Server et décide de servir une réponse mise en cache ou une requête le serveur API. L'avantage de cette approche est de préserver la logique de mise en cache de votre serveur API. L'inconvénient est qu'il a besoin d'un autre serveur.