業務系統請求zabbix圖表性能調優

性能調優實踐

• 性能調優實踐
  • 背景
  • 問題分析
  • 後端優化排查
  • 前端優化排查
  • 後端長響應排查
  • zabbix server 優化
  • 總結

背景

用 vue.js 的框架 ant-design vue pro 實現的一個監控系統，後端用第三方開源組件 zabbix 提供監控數據採集，前端的展現中一個頁面會同時請求 N 個圖表，頁面響應時間很慢，極端狀況下甚至達到 10s ， 用戶體驗不好，因此領導給了個小任務，優化整個頁面的請求響應。

領導發現頁面響應很慢，說了一句：「這些圖表顯示這麼慢，應該一開始就想着優化的」，這裏我以爲這個觀點有待商榷，最近在讀《重構》這本書，裏面的一個觀點我很認同：「作任何事情，先作出來，再優化」，這是一個應用面很廣的策略，跟 Linux 的哲學之一「單個程序負責一個小功能」的組織模式，都有普遍用法；當工期有限的狀況下，先把東西作出來（這裏不光指代程序，而是任何產品或者其餘交付物），再考慮優化它，由於有了產出物纔會有後續的東西，並且任何人不可能一開始就把全部的狀況和變化的需求考慮得面面俱到。Linux 哲學裏的那句話一樣能夠用於人員組織、社會分工合做方面，專人專事，讓專業人士來作（好比：黑人擡棺），效率不言而喻。

顯示很慢的圖以下：

問題分析

以前歷來沒有作過性能優化和分析，此次從零開始優化，須要本身認真分析排查，這個頁面會請求同一個接口，不獲取不一樣監控指標的圖表數據，大概 10-20 個圖表渲染，在排查以前想到可能的性能瓶頸：

• 前端頁面優化很差（前端用的 axios.all 來發送多個併發請求，頁面會在全部後端響應後才渲染，可能瓶頸在這裏）
• 後端接口的併發沒有優化過，可能性能瓶頸在這裏
• zabbix 這個開源中間件的響應時間過慢，負載太高
• mysql 數據庫引擎沒有優化，形成性能太低

後端優化排查

做爲全棧開發者，首先想到的是從後端服務開始優化，而沒有優化經驗怎麼入手，固然是先找輪子了，Google 找了一下工具，有以下可用：

• 阿里的 Arthas java診斷工具
• OneAPM（鏈路追蹤，相似於 skywalking 之類的工具，甚至能夠監測個人 springboot項目）
• Oracle 的 Java Mission Control
• 淘寶的Tprofiler、Jprofiler
• MyBatis-Plus 性能分析插件（這裏個人後端是 springboot + Mybatis-Plus ， 這個插件能夠幫助我分析 SQL 慢查詢，打印出全部的查詢語句）

詢問了下同事，發現你們也沒什麼優化經驗，因此我選用了以前瞭解了一點的 Arthas 工具做爲診斷。

進入 Arthas 的官網，能夠用它的在線教程快速入門（它是一個沙盒的 linux 環境，可以快速掌握 Arthas 的基礎使用和概念），而後，知道使用方法後，把 Arthas 的 jar 包放到個人 centos 線上測試環境中（Arthas 自己也支持 windows 的，能夠本地調試）

java -jar arthas-boot.jar

而後用 trace 命令來追蹤某個方法調用鏈路上的耗時

trace xxxx.xxx  xxx

此時，咱們請求前端代碼，就能在後臺看到對這個調用方法的每一步的耗時了

此時，咱們就能夠去具體的代碼分析耗時緣由了，重複 trace 能夠進一步精肯定位哪一個方法開銷最大。

Arthas 還有不少很是強大的功能，對於 java 程序員很是友好，建議自行探索：

Arthas GitHub 地址

Arthas 使用指南

發現接口響應時間爲 500 ms 後，感受性能瓶頸可能不在後端（固然，這裏確定還有必定的優化空間，可是不是主要矛盾）

前端優化排查

發現後端接口響應時長沒有那麼誇張以後，把目光放到了前端上來，F12 打開了 chrome 瀏覽器的開發者工具後，發現幾個問題：

1. 同一個接口併發了不少次
2. Stalled 和 Waiting（TTFB）很長

繼續 Google ，搜索 同時發送多個請求形成 chrome stalled 時長過大（固然用英文關鍵詞搜索），果真在 stackoverflow 發現了這個問題的解答，[https://stackoverflow.com/questions/27513994/chrome-stalls-when-making-multiple-requests-to-same-resource]，裏面提到了幾種解決方式：

1. 給 response header 增長 Cache-Control: no-cache, no-store ，這個我在後端增長後沒有效果，這裏別人討論的是瀏覽器的緩存機制形成請求過慢
2. 給咱們的請求 url 後面增長一個隨機數，好比 ?ran='+Math.random() ，讓請求不一致，達到欺騙瀏覽器，讓它每次都發送一個新的請求，這個實驗後也不能讓響應時間變短

此時的我陷入了沉思，問題究竟處在哪裏？同事提醒我一個規律，超過 6 個請求後，後面的都會開始有一串灰色的長耗時（就是咱們看到的 stalled），另一個同事說好像是 jquery 的限制仍是怎樣，繼續搜索，發現這個是 瀏覽器對同一個域名的多併發請求個數的限制，參考博文：

• 瀏覽器併發請求限制
• 百度同窗的追查，未解決，但思路很好
• v2ex的方案討論

發現了這個限制以後，咱們把圖表的請求個數限制在6個之內，跟以前相比頁面渲染速度確實有明顯提高，規避了請求數量過多形成 stalled 的問題，固然，這個只是一種解決方案，v2ex 上的同窗有不少其餘可參考的解決方式。

參考騰訊的藍鯨監控裏的圖表繪製，它們採起了分頁請求控制數量，儘可能給客戶展現少的圖表，同時提供每頁顯示更多的選擇（每頁 4 個圖表秒開，8個的時候就開始有 loading 的效果了）

解決了前端超過 6 個請求的阻塞問題，問題到了有的請求 Waiting（TTFB）很長上來了，這又是個什麼呢？搜索一番發現，這個是服務端的響應（看來後端仍是頗有優化空間的，參考博文：ttfb是什麼）

後端長響應排查

這個圖表請求接口有的會特別慢，甚至有的會 2-3 秒，定位到問題出在跟三方組件 zabbix-server 的請求交互上，這是很是須要優化的，打開咱們的 fiddle 抓包工具看請求：

fiddle 使用小技巧

控制面板-Internet 選項-鏈接-局域網設置-代理服務器（不勾選爲 LAN 使用代理服務器）

設置地代碼的代理端口爲 8888 （fiddle 默認使用的就是 8888）

這樣設置後，fiddle 就只會抓取我本地 idea 發送的請求了，過濾掉了瀏覽器裏的干擾請求。

用 Fiddler 抓 Postman的模擬請求

每一個圖表請求分三個：

1. 登陸 zabbix 獲取 token
2. 請求監控項
3. 根據監控項獲取圖表

參考 zabbix 的官方文檔，作了代碼層面的優化：

• 出於性能考慮，緩存 token ，避免每次都登陸請求一個新 token
• 檢索監控項只檢索你須要的屬性（這一點比較好理解，zabbix 服務端咱們用的 mysql 引擎，至關於只查詢特定的字段，跟全表查性能確定不同）

後端優化還包括：用特定的監控項取代發現類型監控項（這個是發現磁盤接口過慢的緣由，會發現 70 多個文件目錄），請求某個主機的全部發現類型監控項寫到咱們的業務庫（只請求一次）等；

zabbix server 優化

單個後端請求的瓶頸在於咱們用 zabbix api 去請求 zabbix server 所返回的過程，因此，對zabbix server 自己的優化也是整個鏈路的重要方面。參考 zabbix 的官方文檔後，有這樣一些方面：

• 歷史數據保存時間儘量的小，這樣數據庫不會超負荷運行，查詢的效率也更高
  [https://www.zabbix.com/documentation/4.0/zh/manual/config/items/history_and_trends]

• 調優zabbix的數據庫引擎，這個是調優最重要的部分（因爲沒有 dba ，本人對數據庫調優也不懂，這個暫時沒法作到，搜索了下咱們使用的 mysql 5.6 使用的是 InnoDB 引擎）
  [https://www.zabbix.com/documentation/4.0/zh/manual/appendix/performance_tuning]

對於 zabbix 自己優化官方文檔還沒整個看一遍，等所有找一遍說不定能找到進一步壓榨性能的方法~

總結

這次優化涉及了不少方面，前端、後端、服務器等，優化後的用戶體驗獲得了提高，也遇到了一些坑，不斷提升本身解決問題的能力，纔是程序員的價值，共勉！