性能調優的標準是什么

這篇文章主要講解了“性能調優的標準是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“性能調優的標準是什么”吧！

前幾天，和一個同學瞎聊，他說，“我們公司的系統從來都沒有經過性能調優，集成測試沒問題后就上線了，上線后也幾乎沒出現過性能問題。”

我當時沒回他。因為沒遇到性能問題不代表程序不存在性能問題，只能說明系統的訪問量有點小。有印象吧?每次明星爆出個大瓜，微博就掛了，那就是因為短時間內訪問量暴增后，扛不住壓力，出現了性能瓶頸。

大部分的性能問題都是由于訪問量過大導致的，我記得汪峰在京東做過一次直播，那畫面卡成狗，幾乎沒法下單，畫面都出不來。因為京東之前沒做過直播，沒遇到這么大訪問量，估計那次活動結束后，直播方面的開發沒少挨批。

還有一部分性能問題是隨著時間積累爆發的，程序在服務器上運行一段時間后就要重啟，否則某個時間節點內存就突然爆掉了。反正我司一些項目就遇到過這方面的尷尬，一開始的解決方案就是寫個腳本，在夜深人靜的時候，偷偷地重啟釋放一下內存。

在性能方面要求最高的我認為就是  12306，搞不好是要被全國人民罵街的。以前在蘇州的時候，不論是不是節假日，每次坐火車回洛陽，或者從洛陽去蘇州，都感覺同伴好多啊，怎么這么多人坐火車，不是南下就是北上，不是東進就是西出。遇到春運的時候，12306  承載的壓力可想而知有多大，秒殺活動壓根沒法和它相提并論。

如果有小伙伴為 12306 工作過，那可以吹一輩子的牛逼了，你比在淘寶雙十一工作過的小伙伴牛逼一萬倍(嗯，我先替你吹一波，據說 12306 的高峰訪問是  10 億 PV，非常 BT)。

知道了性能調優的重要性后，我來問問小伙伴們，什么時候介入性能調優會比較好?

如果你的回答是“越早越好”，那顯然是錯誤的答案。

我在之前的文章中提到過軟件開發的一條原則，就是“Done is better than perfect”，因為“perfect is never  done”。性能調優是一項持久戰，很早就開始介入，并不是一件好事。

你想啊，系統第一時間上線才是最重要的，不然你一邊想著性能調優，一邊疲于開發進度，可能兩者都做不好，反而拖累了系統研發的進度。等你系統上線了，可能用戶已經被別的系統搶走了，你永遠都沒有性能調優的機會了。

不要總想著把所有的功能做完善，做完美后再上線，應該在產品具有一定的雛形后就立即上線試錯，根據用戶的反饋，根據市場的需求再去考量是否追加一些其他的功能或者優化。

那我再來問問小伙伴，哪些因素會成為系統的性能瓶頸呢?閉上眼睛，轉個圈，想一想。

• 數據庫：幾乎所有的系統都會用到數據庫，大量的數據庫讀寫操作會嚴重影響到系統的性能，所以數據庫緩存技術 Redis  變得越來越重要。另外，系統運行時間久了之后，數據量就會變得非常大，不僅需要在 SQL 上做很多優化，還要在分庫分表上下足功夫。

• 網絡：如果你家的網速很慢，那就要去問問運營商，你家的帶寬多少。或者，至少檢查一下，你家的網線是百兆的還是千兆的，雖然網線都很短，短到只有貓到路由器那么一小節。網絡帶寬如果太小的話，就意味著數據傳輸得很慢，就像跑車到市區，搞不好還沒有自行車快。

• 磁盤：我家里的臺式機都換成了固態硬盤，換了之后的速度就比之前普通硬盤的快很多。多說一點，數據庫的讀寫操作就是磁盤 I/O，而 Redis  之所以快，就是因為 Redis 操作的是內存，但 Redis 牛逼的一點在于它不僅可以做緩存，還可以將數據持久化到磁盤。

• 內存：內存的讀寫速度比磁盤快得多，但空間遠沒有磁盤那么大，一般家用的計算機內存在 16G 已經是很高的配置了。眾所周知，Java 程序是通過 JVM  分配內存的，創建的對象都放在堆內存上，操作起來就很快，但如果代碼寫得有問題的話，就很容易造成內存溢出。

• CPU：CPU 的計算速度快到超出人的想象，所以阿爾法狗可以輕松地打敗柯潔。如果，我真的是說如果啊，放在 CPU  還是奔騰的年代，柯潔還是可以輕松打敗阿爾法狗的。如果程序涉及到大量的上下文切換，或者造成 JVM 頻繁的 GC，就很容易長時間占用  CPU，導致出現性能問題。

在實際的工作當中，小伙伴們也可以按照上面的順序進行性能調優。一開始，不要盲目對內存和 CPU  下手，這個難度有點大，并且效果不明顯;搞不好，還會影響到整個系統的使用。先從數據庫、網絡和磁盤著手優化，很容易看到效果，并且不容易出錯。

最后一個問題，小伙伴們知道系統的性能指標嗎?

1)響應時間

很多年以前，我干過一件很蠢的事。公司有一臺閑置的云服務器，是 Windows Server  版的，剛好有一客戶想體驗我司的系統，我就沒想那么多，把系統部署到了這臺云服務器上。

結果呢?

首頁打開的速度超級慢，慢到需要將近一分鐘的時間。不僅客戶的下巴驚掉了，我自己的也掉了。

為了挽回顏面，我對首頁相關的后端和前端做了很多優化，后端刻意使用了緩存技術，減少了 SQL 語句的查詢;前端壓縮了 JavaScript 和  CSS，減少了請求數，甚至更換了 CDN，使用了圖片懶加載，但收效甚微。

最后靜下心來想了想，同樣的代碼，部署到 Linux 環境下的那個系統就很快，就算是第一次打開首頁需要加載資源，響應時間仍然短到無法感知。于是就把  Windows Server 重裝成了 CentOS，效果立竿見影，響應時間短到離譜。

那，一個系統的性能好不好，響應時間(指系統對請求作出響應的時間，比如用戶打開首頁)就是最明顯的一個直觀上的指標。對于游戲來說，響應時間小于 100  毫秒還算不錯，響應時間在 1 秒左右勉強接受，如果響應時間達到 3 秒就沒法玩了。

2)吞吐量

吞吐量(Transaction Per Second)是指系統在單位時間內處理事務的數量，一個事務可能包含多次請求，它反映出系統承受的壓力。

需要注意的是，TPS 和 QPS 是不一樣的，后者指的是單位時間內請求的數量，當用戶的操作只包含一個請求接口時，TPS 和 QPS 沒有區別。

吞吐量可以細分為網絡吞吐量和磁盤吞吐量。前者是指在某個時刻，在網絡中的兩個節點之間，提供給網絡應用的剩余帶寬。即在沒有幀丟失的情況下，設備能夠接受的最大速率。后者是指單位時間內系統能處理的  I/O 請求數量，I/O 請求通常為讀或寫數據操作請求，關注的是隨機讀寫性能。

最后來簡單總結一下。性能調優非常重要，不僅用戶體驗好，系統穩定，更能體現出真正優秀的編碼水平。我相信所有的小伙伴都能寫出跑的通的代碼，但至于痛不痛快，就需要在性能方面有所研究了。

換句話說，如果你跳槽到一家公司，恰好解決了原有系統的性能瓶頸，那不得了啊，兄弟，你立馬就得到公司重用了!

感謝各位的閱讀，以上就是“性能調優的標準是什么”的內容了，經過本文的學習后，相信大家對性能調優的標準是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！