# 從 HackerEarth 用 Apache 擴展 Python 和 Django 的 13 個簡單技巧 > 原文： [http://highscalability.com/blog/2014/2/10/13-simple-tricks-for-scaling-python-and-django-with-apache-f.html](http://highscalability.com/blog/2014/2/10/13-simple-tricks-for-scaling-python-and-django-with-apache-f.html)  [HackerEarth](http://www.hackerearth.com/) 是一項編碼技能實踐和測試服務，在一系列寫得很好的文章中描述了構建站點的試驗和磨難，以及它們如何克服它們：[使用以下方法擴展 Python / Django 應用程序： Apache 和 mod_wsgi](http://engineering.hackerearth.com/2013/11/21/scaling-python-django-application-apache-mod_wsgi/) ，[編程方面的挑戰，正常運行時間和錯誤（2013 年）](http://engineering.hackerearth.com/2014/01/22/programming-challenges-uptime-mistakes/)，P [ ost-mortem：2014 年 1 月 25 日的大故障](http://engineering.hackerearth.com/2014/01/27/big-outage-25-january/)，[強大的實時服務器](http://engineering.hackerearth.com/2013/05/31/the-robust-realtime-server/) ， [100,000 個強大的 CodeFactory 服務器](http://engineering.hackerearth.com/2013/03/12/100000-strong/)，[具有 Django 和 HAProxy 的擴展數據庫](http://engineering.hackerearth.com/2013/10/07/scaling-database-with-django-and-haproxy/)，[連續部署系統](http://engineering.hackerearth.com/2013/08/05/continuous-deployment-system/)， [HackerEarth 技術堆棧](http://engineering.hackerearth.com/2013/03/20/hackerearth-technology-stack/)。 這些文章的特征并使其特別有用，是對改進的驅動力和對報告哪些無效以及如何確定哪些有效的開放態度。 正如他們所說的那樣，當您僅由 3-4 名工程師組成的團隊來構建復雜的產品時，就會發生錯誤，但是對基礎架構的投資使他們可以進行更多的休息，在班加羅爾的街道上漫游，而他們的服務器每分鐘很高興地為成千上萬的請求提供服務 ，同時輕松達到 50,000 個用戶群。 這是他們做事的方式： **HackerEarth 的當前體系結構：**前端服務器； API 服務器； 代碼檢查器服務器； 搜索服務器-Apache Solr &彈性搜索； 實時服務器-使用 Tornado 編寫； 狀態服務器； 工具鏈服務器（主要用于持續部署）； 集成測試服務器； 日志服務器； Memcached 服務器； 很少有服務器可以處理數據分析數據庫和后臺作業。 RabbitMQ，Celery 等粘合許多服務器； 監控服務器； 數據庫經過分片并通過 HAProxy 進行負載平衡。 1. **刪除不必要的 Apache 模塊**。 節省內存并提高性能。 通過只包含您需要的內容，您可以將加載的模塊數量減少一半。 2. **使用 Apache MPM（多處理模塊）工作者**。 通常，對于高流量服務器來說，這是一個更好的選擇，因為它比前叉 MPM 占用的內存少。 3. **保持活動狀態**。 CloudFront 提供了靜態文件，實驗表明，這樣做效率更高，進程/線程可以自由地即時處理新請求，而不必等待請求到達較舊的連接。 4. **mod_wsgi** 的守護程序模式。 線程和進程的數量是恒定的，這可以使資源消耗可預測，并防止流量高峰。 5. **調整 mpm-worker 配置**。 他們在經過大量試驗后顯示了他們使用的配置，這有利于他們的應用程序類型，這種類型的應用程序比 CPU 占用更多的內存。 6. **檢查配置**。 啟用模塊 mod_status.so 和 mod_info.so 以查看 Apache 的運行方式。 這些信息幫助他們大大減少了我們必須運行的服務器數量，并使應用程序更穩定，更能抵抗流量突發。 7. **不會自動縮放**。 100％的正常運行時間是不斷的斗爭。 卷起袖子，朝著這個目標努力。 8. **不要為運行 100 臺服務器**而感到自豪。 編寫更好的代碼并調整系統。 向大量請求拋出服務器并不引以為豪。 例如，這意味著確保請求不會查詢數據庫 20 次。 9. **異步代碼檢查器服務器排隊系統**。 重寫代碼檢查器服務器排隊系統以使其異步，從而大大減少了其前端服務器上的處理開銷。 10. **使用龍卷風進行認真的平行作業**。 “ socket.io”模塊無法擴展到超過 150 個同時連接。 Nowjs 還泄漏了文件描述符。 11. **分片數據庫和數據庫路由器**。 對數據庫進行分片可減少單個數據庫的開銷，并進一步減少查詢延遲。 12. **緩存它**。 在內存緩存中有超過一百萬個鍵值對，會話以 redis 維護，其他任何持久性數據都進入 MySQL 或 S3，但是大多數緩存都保留了適當的生命周期。 13. **持續部署**。 手動更新生產中的代碼更改會使他們發瘋，這將完全浪費時間。 我實際上很喜歡這篇文章，但是請不要開始使用鏈接誘餌標題。 我通常會忽略帶有此類標題的內容，直到我意識到它具有高可伸縮性，我幾乎跳過了這一標題。 確實。 這不是一些愚蠢的嗡嗡聲。這些文章的內容并不保證會被貶低為“＃X 的簡單技巧”標題。 實際上，我嘗試了各種各樣的內容。 有些長，有些短。 一些原始的，一些其他的。 如果您感興趣的話，有些則精心策劃了其他細節，有些則是獨立的。 有些是針對初學者的，有些是針對專家的。 一些非常具體，一些非常籠統。 因此，任何一篇帖子都可能不是您的事，但這并不意味著它不會成為某人的事。 項目符號格式是傳達特定想法的最快方法。 這些想法可能對許多人來說都是舊帽子，或者是新的有趣的東西。 如果有興趣，您可以參閱參考的源材料以獲取更多詳細信息，這正是這個主意。 否則，您可以繼續前進，這確實是個主意。 我認為前兩個評論僅表示他們不喜歡標題，因為它看起來像是個騙人的把戲。 但正如他們也指出的那樣，您的文章始終都是出色的，這就是為什么繼續閱讀它的原因。 確實，內容沒有問題。 只是 linkbait 的頭銜（不公正地）。 jpj，完全是。 :)