We have this API to our ordering system in our Call-Center, that our online-ordering communicates with. But lots of the requests and responses are the same, more or less static - but the API server generates them, it don't just supply a static file.
What do you suggest as the best approach for caching XML responses? I have had a look at Zend_Cache. But from what i understand, i think it's client/session -based, i would like all clients to take advantage of the same cache.
Also every pageview does a pricerequest for the contents of the basket, what caching do you suggest for this. I think Zend_Cache maybe could come into play here !?
Basicly what i need, is to take the load of the API server, so it has more resources to hanlde price requests, and other requests that changes per request.
Update: 13. Dec. 2010 10.45
Request timing
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]
This is the requests for a single pageview, showing a page of side orders, and the basket contains 2 items.
Based on these times, do you think i will get a considerable difference by caching the data? These times is no-load-at-all, so at high-load the caching could probably come in handy.
I don't see an obvious way to do much caching on the pricerequest requests that are basket-dependent. These strike me as probably session-based, highly variable, so computing them per-request seems pretty necessary.
The other requests - the "API requests" - if they truly are as static as you suggest, then they seem to be a great candidate for straight-up Zend_Cache with a File or Memcached backend. Just need to figure out an algorithm for generating a unique key for each of the static API requests you wish to cache.
You could even specify an infinite lifetime in the frontend options and run a cron job to repopulate the cache on whatever frequency you think is reasonable enough to keep the content fresh.
Just thinking out loud.
Cheers!
Zend_Cache is not session-based. It has a number of backends to store the cached data in. For instance, you can setup a memcached server on your network and store the XML in there. You could cache by function call or entire page results or by arbitrary keys.
You can find a number of articles about Zend_Cache at Devzone
Another option would be to add a Caching Proxy between your API Server and your clients that transparently handles any requests to your API Server and decides whether to serve a cached response or query the API server. The advantage of this approach is it keeps the caching logic away from your API server. The disadvantage is it needs another server.