用 Python 做到每秒處理上百萬次 HTTP 懇求，或許嗎？或許不能，但直到近來，這已成為實際。
許多公司都在為了提高程序的履行功能和下降服務器的運營本錢，而放棄 Python 去選擇其它編程語言，本來這麼做並不是有必要，因為 Python 完全可以擔任這些使命。
Python 社區近來做了很多對於功能的優化。CPython 3.6 重寫了新的字典然後全部提高解析器的履行功能。因為引進更快的調用規矩和字典查詢緩存，CPython 3.7 乃至還要更快。
我們可以用 PyPy 的 Just-in-Time 來編譯雜亂的科學核算使命，NumPy 的測驗套件也優化了和 C 拓展的兼容性，同時 PyPy 還方案於本年晚些時候做到和 Python 3.5 保持一致。
這些振奮人心的改變鼓勵著我想要有所立異，Python 所擅長的範疇很多，我選擇了其間一個：Web 和 MicroServices 開發。
瞭解 Japronto!
Japronto 是一個全新的，為微服務量身打造的微框架。實現它的主要目標包含夠快、可擴展和輕量化。的確它快的嚇人，甚至遠比 NodeJS 和 Go 還要快的多的多。要感謝 asyncio，讓我可以同時編寫同步和異步代碼。
Python 的微框架(藍色)、NodeJS 和 Go (綠色) 和 Japronto (紫色)
勘誤表：用戶 @heppu 提到，如果謹慎點用 Go 的 stdlib HTTP 服務器可以寫出比上圖的 Go 快 12% 的代碼。另外 fasthttp 也是一個非常棒的 Go 服務器，同樣的測試中它的性能幾乎只比 Japronto 低 18%。真是太棒了！更多細節查可以看 https://github.com/squeaky-pl/japronto/pull/12 和 https://github.com/squeaky-pl/japronto/pull/14
想要一起學習python的可以加群556982049，群裡有大量學習資料，還有大神解答問題
咱們能夠看到本來 Meinheld WSGI 服務器已經和 NodeJS 和 Go 的功能差不多了。儘管它用的是堵塞式設計，但仍是要比前面那四個要快的多，前面四個用的是異步的 Python 解決方案。所以，不要容易信任他人那些對於異步體系老是比同步體系更快的說法，儘管都是併發處理的問題，但現實遠不如想象的那麼簡單。
儘管我僅僅用 “Hello World” 來完結上面這個對於微結構的測驗，但它清晰的展示了各種服務器結構的處理才能。
這些測驗是在一臺亞馬遜 AWS EC2 的 c4.2xlarge 實例上完結的，它有 8 VCPUs，數據中心選在聖保羅區域，同享主機、HVM 虛擬化、一般磁盤。操作體系是 Ubuntu 16.04.1 LTS (Xenial Xerus)，內核為 Linux 4.4.0–53-generic x86_64。操作體系顯現的 CPU 是 Xeon® E5–2666 v3 @ 2.90GHz。Python 我用的版本是 3.6，剛從源碼編譯來的。
公正起見，一切程序，包含 Go，都只運行在單個處理器內核上。測驗東西為 wrk，參數是 1 個線程，100 個連接和每個連接 24 個懇求(累計併發 2400 次懇求)。
HTTP 流水線
HTTP 流水線在這裡起著決定性的因素，由於 Japronto 用它來做履行併發懇求的優化。
大多數服務器把來自客戶端的流水線和非流水線懇求都天公地道，用相同的方法處理，並沒有做針對性的優化。(實際上 Sanic 和 Meinheld 也是靜靜的把流水線懇求當做非流水線來處理，這違反了 HTTP 1.1 協議)
簡單來說，經過流水線技能，客戶端不必比及服務器端回來，就可以在同一條 TCP 鏈接上持續發送後續的懇求。為了保證通訊的完整性，服務器端會依照懇求的次序逐個把成果回來給客戶端。
細節優化進程
當成堆小的 GET 懇求被客戶端以流水線打包發送過來，服務器端很也許只需要一次體系調用，讀取一個 TCP 數據包就能拿到悉數的懇求。
體系調用，以及在內核空間到用戶空間之間移動數據，相比起在進程內部移動數據，本錢要高的多。這即是為何不到萬不得已，要盡也許少做體系調用的次數。
當 Japronto 收到數據併成功解析出懇求序列時，它會測驗盡也許快的把這些懇求履行完結，並以正確的次序兼併一切成果，然後只履行一次體系調用發送數據給客戶端。實際上由於有 scatter/gather IO 這麼的體系調用，兼併的工作並不需要自己去完結，只不過 Japronto 暫時還沒有用到這些功用。
但是工作並不老是那麼完美，有時候懇求需要消耗很長時刻去處理，等候完結的進程增加了不必要的延遲。
當咱們做優化時，有必要思考體系調用的本錢和懇求的預期完結時刻。
經過優化 Japronto 拿到了 1,214,440 RPS 的成績
除了利用客戶端流水線懇求，和優化調用，還有一些其它可用的技能。
Japronto 簡直都是用 C 寫的。包括解析器、協議、連接辦理、路由、懇求、應答等目標都是用 C 拓展寫的。
Japronto 力求做到 Python 的懶加載，比方，協議頭的字典只要在被企圖懇求屆時才會被創立，別的一系列的目標也只要在首次運用時才會被創立。
Japronto 運用超牛逼的 picohttpparser C 庫來解析狀態、協議頭以及分片的 HTTP 音訊體。Picohttpparser 是直接調用現代 CPU 集成的 SSE4.2 拓展文本處理指令去迅速匹配 HTTP 符號的鴻溝(那些 10 年前的老 x86_64 CPU 都有這玩意兒)。I/O 用到了超棒的 uvloop，它是一個 libuv 的封裝，在最底層，它是調用 epoll 來供給異步讀寫告訴。
想要一起學習python的可以加群556982049，群裡有大量學習資料，還有大神解答問題
Picohttpparser 依賴 SSE4.2 和 CMPESTRI x86_64 的特性做解析
Python 是有垃圾收集功能的語言，為避免不必要的增加垃圾收集器的壓力，在設計高性能系統時一定要多加註意。Japronto 的內部被設計的嘗試避免循環引用和儘可能少的分配、釋放內存，它會預先申請一塊區域來存放對象各種，同時嘗試在後續請求中重用那些沒有被繼續引用的 Python 的對象，而不是將那些對象直接扔掉。
這些預先申請的內存的大小被固定為 4KB 的倍數。內部結構會非常小心和頻繁的使用這些連續的內存區域，以減少緩存失效的可能性。
Japronto 會盡可能避免不必要的緩存間複製，只在正確的位置執行操作。比如，在處理路由時，先做 URL 解碼再進行路由匹配。
想要一起學習python的可以加群556982049，群裡有大量學習資料，還有大神解答問題
相關推薦
