緩存XML響應

我們將此API用於我們的呼叫中心訂購系統，即我們的在線訂購通信。但是很多請求和響應都是相同的，或多或少是靜態的 - 但API服務器生成它們，它不僅僅提供靜態文件。緩存XML響應

作爲緩存XML響應的最佳方法，您有何建議？我看了一下Zend_Cache。但根據我的理解，我認爲這是基於客戶端/會話的，我希望所有客戶端都能利用相同的緩存。

此外，每個綜合瀏覽量都會爲籃子的內容做一個pricerequest，您對此建議使用什麼樣的緩存。我認爲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]

這是一個單一網頁瀏覽請求，顯示側的訂單頁面，和籃包含2項。

基於這些時間，你認爲我會通過緩存數據獲得相當大的差異嗎？這些時間完全沒有負載，因此在高負載情況下緩存可能派上用場。

來源

2010-12-10 Phliplip

我沒有看到一個顯而易見的方式來對基於籃子的pricerequest請求進行大量緩存。這些可能會引起我基於會話的，高度可變的，因此按照請求計算它們似乎非常必要。

其他請求 - 「API請求」 - 如果它們確實如你所建議的那樣是靜態的，那麼它們似乎是直接使用File或Memcached後端的Zend_Cache的理想選擇。只需要找出一個算法來爲每個希望緩存的靜態API請求生成一個唯一的鍵。

您甚至可以在前端選項中指定無限生命週期，並運行cron作業以任何頻率重新填充緩存，而頻率您認爲足夠合理以保持內容的新鮮度。

只想大聲。

乾杯！

來源

2010-12-10 15:51:29

偉大的想法:)關於價格請求，我想在會話中保存最後一個響應，並且只更新/刷新響應，如果有任何更改籃子的內容。但是你可能是對的，我可能會將更多或更少的靜態請求存儲在一個文件中。我已經更新了最初的帖子，列出了每個請求從API獲取的日誌記錄 – Phliplip 2010-12-13 09:32:11

正確的是，如果籃子沒有變化，就不需要做新的價格申請。接得好。 ;-) – 2010-12-13 11:03:54

接受你的答案，因爲我使用了Zend_Cache文件和一個cron作業來更新緩存。我們立即看到在線訂購的加載時間下降了50％:)沒有科學的方法，只需點擊鏈接即可加載計數秒。 – Phliplip 2010-12-14 07:50:46

Zend_Cache不是基於會話的。它有一個number of backends to store the cached data in。例如，您可以在網絡上設置一個memcached服務器並將XML存儲在那裏。您可以通過函數調用或整個頁面結果或任意鍵進行緩存。

你可以找到許多articles about Zend_Cache at Devzone

另一種選擇是增加你的API服務器和您的客戶端透明地處理你的API服務器的任何請求，並決定是否送達緩存的響應或查詢之間的高速緩存代理API服務器。這種方法的優點是它使緩存邏輯遠離你的API服務器。缺點是它需要另一臺服務器。

來源

2010-12-10 09:56:43 Gordon

要考慮的緩存代理是Varnish（http://www.varnish-cache.org/）和Squid（http://www.squid-cache.org/）。 – ivy 2010-12-10 12:39:48

另一個服務器*應用程序*，但不一定是另一個*物理服務器*。 – 2010-12-12 12:43:47

@ElYobo我沒有說，我呢？ ;） – Gordon 2010-12-12 12:51:25

回答

相關問題