2015-10-31 76 views
1

我正在一個我想在App Engine上託管的網站上工作。我的App Engine腳本是用Python編寫的。現在讓我們假設你可以在我的網站上註冊並擁有用戶檔案。現在,用戶配置文件是一種廣泛的,有超過50個不同的ndb屬性(只是爲了舉例)。應用程序引擎:幾個大腳本或很多小腳本?

如果用戶想要編輯他的記錄(他可以擴展),他可以通過我的網站發送請求到應用引擎後端。

配置文件是節的方式,通常約5至10屬性屬於頁面的小部分或容器。在服務器端,我會有多個小腳本來處理編輯整個Profile的小部分。例如,一個腳本會更新「地址信息」,另一個腳本會更新「興趣」和「關於我」的文本。這樣我最終有5個腳本左右。優點是每個腳本都易於維護,只能做一件特定的事情。但我不知道這樣的事情是否聰明,表現明智。因爲如果我在頁面的其餘部分保持這種習慣,我可能最終會得到大約100個或更多不同的.py腳本和一個非常大的app.yaml,我不知道它們在Google服務器上的緩存效率如何。

所以TL;博士:

很多小後端腳本在我的App Engine的後端執行小任務一個好主意,或者我應該使用一些腳本,可以處理不同的任務,整個陣列?

回答

3

每次啓動應用程序的實例時都必須加載一個單一的大腳本,這可能會影響實例啓動時間,啓動實例的每個請求的響應時間以及實例的內存佔用量。但它可以立即處理任何請求,不需要加載其他代碼。

多個較小的腳本可以延遲加載,點播,您的應用程序啓動後,提供的優勢也許吸引一些應用程序:

  • 主要的應用程序/模塊腳本可以保持較小,這保持實例啓動時間短
  • 應用程序的內存佔用量可以保持較小,在延遲加載的文件處理程序代碼未加載,直到有這樣的處理程序請求 - 有趣的很少使用的處理器
  • 響應時間的額外延遲對於需要l的請求由於只需要加載一個較小的腳本,因此導致處理程序代碼更小。

當然,缺點是一些請求會比平時延遲更長由於處理程序腳本加載:在最壞的情況下,受影響的請求的數量是每每一個實例一生腳本的數量。

更新用戶配置文件不是經常做的事情,我認爲這是一個很少使用的功能塊,因此將其處理程序放在單獨的文件中看起來很吸引人。將其分割成每個文件一個處理程序 - 我發現也許有點極端。這真的取決於你,你更瞭解你的應用和你的風格。

從GAE(緩存)的下一個預期 - 文件配額是10000個文件,我不會太擔心只有~100個文件。

+0

遵循您的答案:現在我的應用程序沒有主應用程序/模塊。我有一個客戶端應用程序,通過完成基本的Ajax請求來與後端進行交互。當用戶登錄時,會向login.py模塊發送一個POST請求,該請求返回一個令牌。當用戶註冊時,我的signup.py有一個POST請求。等等等等。它們都是獨立的.py文件,在我的app.yaml文件中有單獨的名稱。所以我假設當一個實例無法處理傳入的請求到我所有不同的腳本時,一個新的腳本將啓動並最終緩存我的所有腳本? – Escapado

+1

是的,任何實例都可以爲app.yaml中的任何處理程序提供服務。除了啓動時間之外,它在單個處理程序和許多處理程序之間確實沒有太大區別。我使用單個處理程序,因爲我使用的URL路由模型是基於金字塔的遍歷。如果你使用類似webapp2的東西,它會傾向於有很多小處理程序在app.yaml中註冊。兩者都起作用,它比另一個更合適 - 取決於。 –

3

這裏有兩個重要的考慮因素。

  1. 從客戶機到服務器往返的呼叫數。

當您保存客戶端與服務器之間以及服務器與數據存儲之間的往返時間時,一次調用更新用戶配置文件的執行速度將快於5次調用,以更新用戶配置文件的不同部分。

  1. 寫入成本。

如果在用戶配置文件更新5個屬性並保存它,然後更新等5個屬性,並將其保存,等等,你的寫作成本會高得多,因爲每次更新會帶來寫作成本,包括所有更新索引屬性 - 即使那些你沒有改變。

而不是創建一個包含50個屬性的龐大用戶配置文件,最好在一個實體中保留很少更改的屬性(名稱,性別,出生日期等),並將其他屬性分隔到不同的實體中或實體。通過這種方式,您可以降低寫入成本,但也可以減少有效負載(不需要將所有50個屬性來回移動,除非需要),並簡化應用程序邏輯(例如,如果用戶只更新地址,則不需要更新整個用戶配置文件)。

0

添加到Dan Cornilescu的回答是,將實例寫入/保存到數據庫將重新寫入整個實例(即其所有屬性)到數據庫。如果您要多次使用put(),那麼您將重寫多次實例。除了要執行繁重的任務之外,這將花費你更多的錢。