zabbix我們主要用於資料庫的監控，數量百台，採用passive模式由server向client輪詢資料。監控主要是shell收集資料。
資料庫分布於國內和國外（可定會遇到網路問題，zabbix暫時未做proxy），zabbix server處於國內；
zabbix dasboard上顯示每秒處理 200個左右的事務，這樣的話幾乎是沒有壓力的；但在queue中發現超過10m以上的居然有上百個。
原因分析：
除了國外部分server 由於網路未及時監控到的原因，大部分延遲集中在某client幾個items上。
zabbix server os，資料庫等機會無壓力，頁面開啟順暢。上線時間剛剛2個月，資料量還沒達到一定規模；基本排除zabbix server 效能問題。
起初的處理辦法是：增大poll 執行緒數，增大zabbix server 等待client的timeout時間增大的30s；雖然這樣效果依然不明顯。
分析客戶端：針對延遲比較嚴重的某個item單獨排查，（zabbix_agentd -c /usr/local/zabbix/conf/zabbix_agented.conf $1 $2）提示的訊息為 alarm clock，，汗。。zabbix agent timeout 時間預設為3s， 超過該時間的程式全部被截止，手動指令碼執行大概10秒。現在基本有兩種修改方式：1、修改監控項；2、將zabbix agent監控 timeout時間增大至15秒。。我們採用的後者！
前端效能優化小結
乙個專案只有乙個css，乙個js，使得不同網頁不必每次請求重複的css或者js內容。並且使用打包工具可以壓縮資源檔案的大小，例如webpack gulp grunt等。使用字型圖表或者svg圖替代傳統的png。向量資源大小更小，渲染速度快，不存在放大後模糊的問題。css的效能優於js 原生js的效能...
Android效能優化 一 優化小結
在前幾篇的部落格中，我從sqlite資料庫 布局 資料處理，網路等方面和大家分享了一些優化的知識。本篇部落格，我將以小結的方式和大家一起回顧在android 效能優化方面的一些注意細節。首先，我們從android資料庫 sqlite來分析了在運算元據庫時我們可以優化的地方，我將其分為了兩部分，分別是...
系統效能優化小結
最近開發過程中，遇到兩次效能優化的需求，幾番努力完成效能要求，乙個因為工作改動量大而沒有付諸實踐，現小結如下。對外提供的網路介面，資料庫資料都走了redis的快取，但是在此情況下，仍然請求在10秒多，資料量大的時候需要快20秒，現要求是秒以內的響應速度。首先對各個方法進行響應時間的日誌新增，執行幾種...