2013-10-22 19 views
0

問題(簡而言之)是:基於緩慢的外部API的Symfony 2 UserProvider:如何緩存/加速它?

我們目前的解決方法太慢了。

  1. Symfony Security組件在每個網頁瀏覽中重新加載用戶。
  2. 用戶從我們自己的UserProvider加載,訪問緩慢的外部API。

來我們的腦海中的第一個想法是:

我們可以緩存從外部API來在本地數據庫或memcache的信息。

我的問題:

  1. 是否有任何包在外面,可以幫助我們實現這一目標?
  2. 我們是否應該處理我們自己的UserProvider中的所有緩存?
  3. 將需要緩存的用戶放入教義實體並使用鏈式提供者首先從教義中加載他們可能更好嗎?在這種情況下,我們如何處理用戶對象的有限生命週期?
  4. 如果不緩存任何內容,只需編寫我們的提供程序刷新函數,以便僅在上次重新載入發生時間過長時才重新載入用戶呢?

關於如何有效地做到這一點的任何其他想法?

乾杯,

蒂莫

+0

是你的外部api是一個像oauth還是custom的standadised類? – Udan

+0

嗨烏丹,API是一個自定義的。我們已經有一個客戶端和一個訪問它的用戶提供者,所以這個問題實際上只是讓它去執行。乾杯,Timon – user2811588

回答

0

既不緩存也不鏈提供商是一「完美」的解決方案,你必須實現當在外部提供程序發生變化(例如,改變後的口令)的用戶,其無效的邏輯。如果我理解正確的話,會要求您經常檢查API。好像你必須在性能和頻繁檢查更新之間妥協。這就是說,我假設你已經有一個自定義的用戶提供程序,它通過API讀取用戶,我沒有看到任何錯誤添加一個緩存作爲依賴,或者可能創建第二個CacheApiUserProvider旁邊你的UserProvider,所以當你在緩存後端出現問題時你可以在它們之間切換。我認爲這不是必需的附加綁定,但您可能需要尋找緩存綁定。

我沒有看到(3)中提出的鏈式提供程序如何幫助您,因爲您只會遇到同樣的限制,即經常檢查外部提供程序中的更改,就像緩存一樣。如果我不得不選擇,我會使用CachedProvider,因爲它幾乎是你想要做的事情,一個更復雜的鏈式提供者只會隱瞞你想解決什麼問題,並混淆未來的維護者(簡而言之:保持它很簡單)。

根據API提供的內容,您可能能夠在後臺運行一個工作人員,從而自動從API獲取新用戶和對現有用戶的更改並將其移至(本地)數據庫,但在這種情況下,我不會懶得建立一個鏈式提供者,只依靠數據庫來更新。