有沒有辦法加快django中的身份驗證功能？

Question

我們使用django爲mysql創建一個json webservice前端。我們在EC2實例上運行apache和django，並在RDS實例上運行MySQL。我們已經開始使用Apache Bench進行性能基準測試，並且獲得了一些非常糟糕的性能數據。我們還注意到，在運行測試時，我們的apache/django實例在非常低的負載下達到100％CPU使用率，並且MySQL實例永遠不會超過2％CPU使用率。

我們正在努力使這個意義上說，孤立的問題，所以我們做了幾個AB測試：

1. 一種從Apache的靜態HTML頁面的請求 - 〜2000個請求/秒。
2. 一個在django中執行一個小型python函數的請求，沒有db交互 - 約1000個請求/秒。
3. 執行我們調用驗證Django的web服務的功能之一，然後做一個非常簡單的查詢來從一個表中記錄的請求 - 11個請求/秒
4. 同3，但評論的電話進行驗證 - - 95個請求/秒。

爲什麼驗證太慢？它是否將數據寫入數據庫，找到pi的十億位數字，是什麼？

我們希望保持呼叫在這些功能中進行身份驗證，因爲我們不希望任何人都可以猜測這些URL，等等。有沒有人注意到身份驗證速度很慢，任何人都可以提出建議一種補救方法？

非常感謝！

Answer 1

我並不是身份驗證和安全方面的專家，但以下是爲什麼會發生這種情況的一些想法，以及可能如何提高性能。

由於密碼存儲在數據庫中，爲了保證其存儲安全，不會存儲明文密碼，而是會存儲它們的散列值。通過這種方式，您仍然可以通過將計算出的輸入密碼與存儲在數據庫中的密碼進行比較來驗證用戶是否已登錄。這增加了安全性，因此如果惡意方會獲得數據庫的副本，解密明文密碼的唯一方法是使用彩虹表或進行暴力攻擊。

這是事情變得有趣的地方。根據摩爾定律，計算機正在以指數方式變得更快，因此計算散列函數在時間上變得便宜得多，尤其是像md5或sha1這樣的快速散列函數。這帶來了一個問題，因爲現在可用的所有計算能力與快速哈希函數相結合，黑客可以蠻力哈希密碼相對容易。爲了解決這個問題，可以做兩件事。一個它多次循環散列函數（散列的輸出被反饋到散列）。然而，這不是非常有效，因爲它僅僅通過常數增加散列函數的複雜度。這就是爲什麼第二種方法是優選的，這是爲了使實際的散列函數更復雜且計算更昂貴。具有更復雜的功能，需要更多時間來計算散列值。即使計算需要一秒鐘，對於最終用戶來說也不是什麼大問題，但對於暴力攻擊來說這是一件大事，因爲必須計算數百萬次散列。這就是爲什麼從Django 1.4開始，它使用了一個名爲PBKDF2的相當昂貴的計算功能。

回到你的答案。正是由於這個功能，當您啓用身份驗證時，您的基準數量會急劇下降，並且您的CPU數量會增加。

以下是一些可以提高性能的方法。

• 從Django 1.4開始，您可以更改默認身份驗證功能（docs）。如果您不需要太多安全性，則可以將默認功能更改爲SHA1或MD5。這應該會提高性能，但請記住，安全性會更弱。我個人的觀點是安全是重要的，值得額外的時間，但如果它沒有保證你的應用程序，這是你可能要考慮的。
• 使用會話。昂貴的散列函數僅在初始登錄時計算。一旦用戶登錄，將爲該會話創建會話，並使用會話標識將cookie發送給用戶。然後在隨後的請求中，用戶上傳cookie，如果會話尚未過期，則用戶將自動進行身份驗證（因爲會話數據已簽名，所以不要擔心安全問題...）。重點在於與計算昂貴的散列函數相比，驗證會話的計算成本更低。我猜測你在ab測試中沒有發送會話cookie。嘗試做一些測試，並添加發送會話cookie並查看它的執行情況。如果發送cookie不是真正的選項，因爲您正在創建JSON API，那麼您可以修改會話後端以通過會話GET參數而不是cookie接受會話數據。然而，不確定這樣做的安全後果是什麼。
• 切換到nginx。我不是部署專家，但根據我的經驗，與Apache相比，nginx對Django更快更友好。我認爲您可能特別感興趣的一個優點是nginx具有多個工作進程的能力，以及使用proxy_pass將請求傳遞給Django進程的能力。如果您將擁有多個工作進程，則可以通過proxy_pass將每個工作人員指向單獨的Django進程，這將有效地向Django添加多進程。另一種方法是如果你使用gevent WSGI服務器，你可以在Django進程中創建一個池，這也可能會提高性能。不知道這些中的任何一個是否會顯着增加你的性能，因爲你的CPU負載已經達到100％，但它可能是一些值得研究的東西。