我是怎麼一步步用go找出壓測性能瓶頸

歡迎你們前往騰訊雲+社區，獲取更多騰訊海量技術實踐乾貨哦~

本文由mariolu 發表於雲+社區專欄

序言：

​ 筆者要在線上服務器load日誌而且重放來測一些機器性能指標。模擬機器資源比較少，相對的被模擬的線上機器日誌量大，假設線上單機qps有1w，那麼5臺機器組成的集羣5w個qps。模擬機器壓測客戶端須要比5w個qps更快，纔有比較意義。

第一章：HTTP初體驗

​ 正所謂「人生苦短，我用python」，python自帶了urllib二、urllib3以及第三方的request。支持的代理訪問、添加請求頭基本知足功能需求。筆者用urllib2+multiprocessing庫順利了碼完代碼運行之，查看qps只有2k多，這顯然遠遠低於需求。在加大進程數到cpu核數的數倍之多，也發現python僅能達到3k多。事出必有因，因而筆者便經過監控界面和shell小工具來找機器各類茬。

第二章：「中世紀黑暗期」

​ 中世紀是黑暗漫長的時期，你作了不少事情，但卻輸出不多，留下來的是嘗試後的經驗總結。從cpu、內存、硬盤、網絡各方面數據看。cpu使用率90%多，內存用滿、硬盤wa很低、網絡千兆網卡滿載。最首先的是把千兆網卡機器替換成萬兆網卡機器。查看timewait的鏈接數達到1w3多。那就先優化下看起來是"瓶頸"的東西。配置tcp_timestamps=1, tcp_tw_reuse=1, tpc_tw_recycle=1。sysctl -p生效下最新的配置，timewait鏈接數沒下去，併發數沒上來。既然硬件該作的設置都完了，那爲何別人家的露娜那麼秀，我家的就是一坨屎呢。

​ 再回過頭來考慮程序架構問題。檢討本身，首先urllib二、request庫是網絡io阻塞的，其次網絡是短鏈接的，再次這麼多進程切換系統開銷也很大。在廣袤的互聯網海洋中遨遊了一番，得出的結論就是grequest庫多是個解決辦法。gevent是個協程庫，它使用greenlet庫提供的基於libev實現的高性能異步網絡框架。Perfect！看起來是那麼的完美。因而又嘗試重寫了程序。但是性能仍是沒有上去。那究竟是不是python語言自身的限制問題，致使cpu高居不下，併發量又上不去呢？這裏留個疑問，到文章的最後再來回答這個問題。

第三章：豁朗開朗

​ 不甘心而且再也不糾結於python，用當下網紅golang重寫下。golang的協程庫號稱是性能優秀，語言層面支持並行的，易於書寫的利器。寫完跑一跑，併發量仍是上不去。一直保持打死都不放棄的精神，筆者再次用go的第二性能利器自帶的golang pprof分析下代碼的瓶頸。pprof生成的報告還能夠用uber第三方組件go-torch生成更直觀的火焰圖。如圖1所示。從火焰圖查看出runtime.gcBgMarkWorker(gc:垃圾回收器)，而且runtime.mallocgc也佔用大量cpu時間。接着進行內存佔用分析，使用go tool pprof -alloc_space replay1 /tmp/mem.prof查看如圖2 所示，敲入top10命令，發現pull_worker累加分配了600多G內存，佔比93%，list pull_worker命令找到該函數的瓶頸點。這個r4變量的初始化放在一個for循環內，r4是用於臨時讀取響應body，這個r4每次請求都重複分配，致使內存居高不下，解決辦法是把他放在for循環外。

終章：總結

​ 好了，至此單機併發量最高能夠到3w了，也差很少達到計劃的目標了。用兩臺這種機器組成的肉雞就能夠知足5w qps的請求了。再來回答以前留下來的問題，python語言併發上不去只是由於，庫不支持從外面提供讀buffer讀取響應body，致使內存暴增，這不是語言自己的問題。相信python並無那麼差。同時，也熟悉了一門新利器go語言。go的原生協程支持和性能分析利器仍是很是直觀很是好用的，力薦！！

圖1：性能瓶頸前的cpu火焰圖

圖2：找到內存使用最多的函數

找到增加最多的代碼

問答

Angular2如何處理http響應？

相關閱讀

HTTP/2之服務器推送(Server Push)最佳實踐

如何備份你的MySQL數據庫

MySQL 8.0 版本功能變動介紹

此文已由做者受權騰訊雲+社區發佈，原文連接：https://cloud.tencent.com/developer/article/1160803?fromSource=waitui

歡迎你們前往騰訊雲+社區或關注雲加社區微信公衆號（QcloudCommunity），第一時間獲取更多海量技術實踐乾貨哦~

海量技術實踐經驗，盡在雲加社區！