Google App Engine低memcache性能

Memcache是其中解決方案可能是絕對的任何東西之一，也沒有人真的給出了正確的答案，也許是因爲沒有。所以我不是在尋找直接的答案，但也許只是讓我朝着正確的方向前進。Google App Engine低memcache性能

對於一個典型的請求，這是我將Appstats信息：

enter image description here

所以，在總共440毫秒的請求，我花342毫秒內存緩存。在這裏，我認爲memcache應該是閃電般的。我一定做錯了什麼。

看看我在我的管理控制檯memcache的統計，我有這樣的：

Hit count: 3848 
Miss count: 21382 
Hit ratio: 15%

我對這個東西不是專家，但我敢肯定，15％是可怕的。

上面的典型請求有點太詳細以至於無法解釋，但基本上，我創建並放置了一個新實體，該實體還更新並放置父實體，該實體還更新並放置與父實體關聯的任何用戶。

縱觀這一切，我總是通過按鍵獲取，從不查詢。哦，我正在使用NDB，所以基本都是memcache stuff is handled automatically。所以我從來沒有真正在自己的代碼中手動觸摸memcache。

任何想法？

編輯：這是我的要求的擊穿

enter image description here

所以我只有2個數據存儲變得和2個看跌期權。其餘的是自動處理memcache的東西。爲什麼它做了這麼多工作？手動處理這些東西會更好嗎？

來源

2012-10-30 Snowman

如果不知道你在做什麼，以及你的數據模型是什麼樣子，就不可能給你任何好的建議。 –

@JasonHall你我想通了。我正在使用NDB，所以我沒有手動處理任何memcache。它的全部自動。所以我想知道什麼會導致它在內存緩存中佔用342？即使在絕對最壞的情況下，如果memcache真的需要那麼長時間？ – Snowman

您可能想要掌握一些什麼/如何進行memcaching - 將它留給NDB不會奇蹟般地解決您的問題，特別是因爲NDB不知道您要做什麼。例如，儘可能使用'set_multi'而不是'set'來批量處理內存緩存請求。 –

讓我們仔細看看您的數據。七個memcache寫入佔用了兩個數據存儲區寫入的時間。這實際上證明了memcache比數據存儲快了3.5倍。

如果對您的應用程序的典型請求需要更新至少三個數據庫實體 - 隨後更新更多實體（關聯的用戶），則無法使此操作「閃電般快」。 Memcache可以幫助您在閱讀條目時比撰寫條目更頻繁。如果讀取和寫入用戶記錄的數量相等，則應考慮使用turning cache off。

您也可以嘗試asynchronous operations和task queues。從您的描述中看，您嘗試首先更新實體，並且只有在更新完成後才更新其父項，因爲這很自然。你可以同時運行這些;這可能需要一些重構，但這是值得的。

其次，更新「所有關聯的用戶」可能是，也許。推遲到後臺產生的任務; Task Queues有一個非常方便的界面。「關聯用戶」不會立即更新，但他們可能不需要！但是，請求的延遲時間會少於此時間。

來源

2012-10-30 20:11:06

所以你有點說，鑑於我更新的頻率實體，這是與memcache預期的行爲？我儘可能使用異步操作。我還沒有考慮任務隊列，但這似乎是一個好主意。 – Snowman

@mohabitar我與AppEngine的經驗是每個系統調用都可以以非零概率「尖峯」（比如說從通常的10ms到50ms）。因此，你調用的RPC調用越多，其中一個調用的概率就越大，並給你更高的延遲。如果您在每次訪問時更新* memcache *和* datastore，則可能會導致操作高峯期的風險更高。如果在兩次寫入之間，您有大量在memcache級別解決的讀取操作，則可能需要這種風險。如果你不這樣做，你可能會更好，沒有緩存。 –

Google App Engine低memcache性能

回答

相關問題