資訊專欄INFORMATION COLUMN
摘要：最近閱讀了很多優秀的網站性能優化的文章，所以自己也想總結一些最近優化的手段和方法。個人感覺性能優化的核心是減少延遲，加速展現。初步以為是這個功能導致的服務掛起，詢問相關操作人員，得到當時的操作過程。
最近閱讀了很多優秀的網站性能優化的文章，所以自己也想總結一些最近優化的手段和方法。
個人感覺性能優化的核心是：減少延遲，加速展現。
本文主要從產品設計、前端、后端和網絡四個方面來訴說優化過程。
在網上看到一句話：好的性能是設計出來的，而不是優化出來的。
感覺好有道理，如果將性能瓶頸扼殺在搖籃里，那么后期的維護成本將變得非常低，并且在避免改造后，都不需要浪費資源了。
1）聊天改版
最近公司有個聊天活動做改版，改版上線后驚喜的發現，監控數據居然減少了將近20W。
更深一步的探究，才知道在頁面初始化時，會發一個請求，去獲取一些文案，但其實這些文案都是寫死的，完全可以寫到頁面本地。
如果在產品設計時，就不是通過接口讀取的方式，那么就可以大大減少瀏覽器和服務器之間的通信。
2）數據遷移
公司有一個審核系統，最近審核人員反應系統使用起來越來越卡。排查后發現，定位到性能瓶頸，是因為數據表巨大導致的，目前已有6千萬條。
其實在一開始設計時，就該能預估到，未來的數據量，感覺還是偷懶了，想快速完成。感嘆前人挖坑，后人埋坑。
起初是想分表，但思慮后還是決定不那么做，最后采用的是MySQL歸檔。
前前后后花了兩周的時間，才將方案落地實現，涉及到運維、QA和我們前端組，人力成本無疑是巨大的。
其實在每次完成優化后，可以再想想能不能將問題泛化，擴大維度，想想其他地方是否有類似問題，總結經驗供他人學習，以及對未發生的問題進行預判。
3）大批量的504
這是在上線監控平臺后不久發現的，504 的請求量太多，這類通信錯誤居然占了25%~30% 左右。
經過排查定位到一個常規的翻卡活動中，產品設計出現了嚴重的問題。
在進行一個翻卡操作時會請求兩個接口，并且每個接口各自發送 3 次通信，這樣會很容易發生 504 錯誤，每天大約有1500個這樣的請求。
首先是給其中一張表加了個索引，然后是將兩個接口合并成一個，并且每次返回 20 條以上的數據，這樣就不用頻繁的發起請求了。
經過改造后，每日的 504 請求從 1500 個左右降低到 200 個左右，減少了整整 7.5 倍，效果立竿見影，大部分的 504 集中在 22 點到 0 點之間，這段時間的活躍度比較高。
還有一個令人意外的發現，那就是監控日志的量每天也減少了 50W 條。
前端的優化手段非常多，常規的其實就是延遲請求和減少頁面渲染次數。
1）預請求
數據預請求是將數據預請求的時機由業務發起請求的時機，提前到用戶點擊時，并行發送數據請求，縮短數據等待時間。
這個需要客戶端配合，在Webview啟動的時候，并行的去請求首屏需要的數據。
經過觀察發現每次請求后端數據的API大概要花100~200ms，如果把這段時間省下來，那么也能減少白屏時間。
在與客戶端溝通時，他們還是表現的比較抗拒的，在他們看來這點時間微不足道，還會增加他們的工作量。
有個人還一直強調瀏覽器內置的緩存規則是一劑靈藥，絕對可以提升頁面的性能，經過討價還價后敲定最終的預請求方案。
2）預加載和懶加載
預加載和懶加載特指的是圖片的加載，其實就是延遲請求時機。
兩者的核心算法就是計算圖片的相對位置，具體參考于此。
這兩招非常有效，可以說是立竿見影，尤其是頁面中圖片量較多以及尺寸較大時，能瞬間提升頁面加載。
之前做過一次偏動畫的宣傳頁，在進入頁面時，立刻請求所有圖片，直接白屏好幾十秒。
3）串行變并行
有一張活動頁面，交互并不多，但是要展示的數據需要經過后臺比較復雜的計算后才能得到。
一開始是將所有的數據都包含在一個接口中，這就導致頁面發起請求后，要白屏好幾秒后，才能慢慢加載。
用戶的等待時間很長，經過排查后發現，其實可以將一些配置參數提取到多帶帶的一個接口中，核心的數據再抽取到另一個接口中。
這樣就是將一個串行的接口分離成兩個并行的接口，先快速的讓用戶看到整個頁面的大結構，例如頭圖、規則等信息。
然后在將數據渲染到合適的位置，形成了一個時間差，對用戶更加友好。
后端主要涉及是Node.js和數據庫的優化，我們組涉及到的此類性能瓶頸并不多，但也會有一些。
1）內存泄露
自研了監控平臺，在剛上線時，就遇到了性能問題，首先是采集的參數在大批量的發送給存儲的服務器時，服務器宕機了。
因為每秒就有幾百甚至幾千的請求發送過來，服務器需要整理數據后加入到數據庫中，當數據量暴增時，服務器就會來不及處理。
這個性能瓶頸發生后，馬上加入任務隊列，服務器就能平穩的運行了。
之后又出現了另一個問題，CPU會在不特定時間段（例如21~22、23~02等）飆到70%，內存也是一路飆升不會下降，明顯是出現了內存泄漏，具體的排查過程可以參考于此。
開通了阿里云的 Node.js 性能平臺，在前前后后調試了三周，有點像探案的過程，才最終定位到一段最為可疑的代碼。
原來是為外部的一個對象反復注冊了一個事件，應該是形成了一個閉包，讓閉包內的變量都無法釋放。
2）數據庫
仍然是在研發監控平時時遇到的性能瓶頸，這次主要體現在數據庫。
監控的日志我都存儲在MySQL中，每日 70W 條記錄，數據量很快達到了千萬級別，在做查詢時，變慢了很多。
那么就得讓索引上了，亞洲舞王尼庫拉斯趙四曾說過：一個索引解決不了的，那就來兩個索引。
我也是這么做的，加了好多個索引，但維度模糊查詢，這個不是加索引能解決的，嘗試了很久，最終還是決定遷移到ElasticSearch中。
效果也是立竿見影的，幾千萬條數據，幾秒鐘就出了結果，令我驚嘆不已。
這里順便說下，我會在什么場景中選擇 MongoDB 作為數據庫的。
MySQL是一種關系型數據庫，會事先聲明表結構，那么對于數據結構不定的記錄，存儲起來會比較費勁。
例如記錄中有許多JSON格式的數據，就比較適合存在 MongoDB，當然了，這類數據也可以轉換成字符串存在 MySQL 的一個字段中。
只是在讀取和寫入時，要經過序列化和反序列化的操作，并且如果要查詢JSON數據的某一個字段時，MySQL中就只能模糊查詢了。
但是平時的話，我還是會盡量將數據存在 MySQL 中，有個很直接的原因是因為線上的 MySQL 有一個功能完善的可視化界面，而 MongoDB 沒有，只有一個我自制的簡陋工具。
3）管理后臺掛起
之前也會偶爾有管理后臺服務掛起的情況發生，但最近會在每天的10點左右發生。
在下圖中，一分鐘內server服務瞬間飆到了 100%，不得不讓我引起注意。 ?
查找那段時間的日志，發現有很多送禮的記錄，反向查詢后，定位到一個導出鏈接。
初步以為是這個功能導致的服務掛起，詢問相關操作人員，得到當時的操作過程。
在預發環境模擬，得到的結果是可以正常導出，所以應該可以排除它的嫌疑。
回想到前天也發生了掛起（不過前天的CPU都比較正常），再次翻查日志，新發現直指審核模塊。
與審核人員溝通后，她們向我一頓吐槽，大倒苦水，說這系統11點后，經常卡頓轉圈。
這個系統后續有很大的優化空間，那么目前首要任務是解決服務掛起的問題。
可以想到的是將審核模塊多帶帶配置一臺服務器，做成獨立服務，這樣也便于觀察。
服務切換其實就是將特定規則的API指向另一個服務，代碼和邏輯都不需要改動，非常方面。
隔天發現仍然會掛起，但是掛起的服務可以定位到審核模塊，運維也找到了一條發生504的接口。
前一天發生的掛起，也是這個接口引起的，順著這條接口查看代碼，并沒有發現什么異常。
打開日志，發現這個接口的響應的確非常慢，要幾分鐘了，再去查其中涉及到的SQL查詢語句，發現也很耗時。
將語句拿到數據庫中執行 EXPLAIN 命令，影響的行數要 311W 多條，命中的索引是 idx_create_time。
而去掉其中的一個日期限制后馬上降到 69 條，命中的是一個聯合索引，回到代碼中，查看邏輯后，發現這個時間限制是多余的，馬上就將其去除。
還有一條SQL語句運行也很慢，影響的行數要 16W 多條，命中的索引是 idx_status，而這個 status 其實只有幾個可選的關鍵字，會影響查詢效率。
于是再創建一個聯合索引，影響的行數降到 1785 條，優化后，再反饋給審核人員。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/124132.html
摘要：而這里的單元格信息是唯一的，所以直接通過為一個空對象賦值即可。和相關的知識和技巧高亮的列單元格采用展示。在中，被選中的單元格會高亮相應的行和列，以提醒用戶。 showImg(https://segmentfault.com/img/bVGkdk?w=900&h=500); XCEL 是一個 Excel 數據清洗工具，其通過可視化的方式讓用戶輕松地對 Excel 數據進行篩選。 XCEL...
摘要：斬從第題開始，到現在也差不多快一年了，回顧紀念一下。當時對回溯動態規劃也都只是上課的時候學過，也并不熟練。最經典的例子就是斐波那契數列了，求第項數列的值。 leetcode 100 斬！從第 1 題開始，到現在也差不多快一年了，回顧紀念一下。 showImg(https://segmentfault.com/img/bVbu461?w=661&h=191); 為什么開始刷題？ 從大一就...
摘要：表示的是兩個，當其中任意一個計算完并發編程之是線程安全并且高效的，在并發編程中經常可見它的使用，在開始分析它的高并發實現機制前，先講講廢話，看看它是如何被引入的。電商秒殺和搶購，是兩個比較典型的互聯網高并發場景。 干貨：深度剖析分布式搜索引擎設計 分布式，高可用，和機器學習一樣，最近幾年被提及得最多的名詞，聽名字多牛逼，來，我們一步一步來擊破前兩個名詞，今天我們首先來說說分布式。 探究...
閱讀 1318·2021-11-24 09:38
閱讀 3256·2021-11-22 12:03
閱讀 4156·2021-11-11 10:59
閱讀 2316·2021-09-28 09:36
閱讀 1031·2021-09-09 09:32
閱讀 3411·2021-08-05 10:00
閱讀 2527·2021-07-23 15:30
閱讀 2972·2019-08-30 13:12
