性能調(diào)優(yōu)的標(biāo)準是什么

這篇文章主要講解了“性能調(diào)優(yōu)的標(biāo)準是什么”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“性能調(diào)優(yōu)的標(biāo)準是什么”吧！

前幾天，和一個同學(xué)瞎聊，他說，“我們公司的系統(tǒng)從來都沒有經(jīng)過性能調(diào)優(yōu)，集成測試沒問題后就上線了，上線后也幾乎沒出現(xiàn)過性能問題?！?/p>

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

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

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

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

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

知道了性能調(diào)優(yōu)的重要性后，我來問問小伙伴們，什么時候介入性能調(diào)優(yōu)會比較好?

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

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

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

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

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

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

• 網(wǎng)絡(luò)：如果你家的網(wǎng)速很慢，那就要去問問運營商，你家的帶寬多少?；蛘?，至少檢查一下，你家的網(wǎng)線是百兆的還是千兆的，雖然網(wǎng)線都很短，短到只有貓到路由器那么一小節(jié)。網(wǎng)絡(luò)帶寬如果太小的話，就意味著數(shù)據(jù)傳輸?shù)煤苈?，就像跑車到市區(qū)，搞不好還沒有自行車快。

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

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

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

在實際的工作當(dāng)中，小伙伴們也可以按照上面的順序進行性能調(diào)優(yōu)。一開始，不要盲目對內(nèi)存和 CPU  下手，這個難度有點大，并且效果不明顯;搞不好，還會影響到整個系統(tǒng)的使用。先從數(shù)據(jù)庫、網(wǎng)絡(luò)和磁盤著手優(yōu)化，很容易看到效果，并且不容易出錯。

最后一個問題，小伙伴們知道系統(tǒng)的性能指標(biāo)嗎?

1)響應(yīng)時間

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

結(jié)果呢?

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

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

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

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

2)吞吐量

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

需要注意的是，TPS 和 QPS 是不一樣的，后者指的是單位時間內(nèi)請求的數(shù)量，當(dāng)用戶的操作只包含一個請求接口時，TPS 和 QPS 沒有區(qū)別。

吞吐量可以細分為網(wǎng)絡(luò)吞吐量和磁盤吞吐量。前者是指在某個時刻，在網(wǎng)絡(luò)中的兩個節(jié)點之間，提供給網(wǎng)絡(luò)應(yīng)用的剩余帶寬。即在沒有幀丟失的情況下，設(shè)備能夠接受的最大速率。后者是指單位時間內(nèi)系統(tǒng)能處理的  I/O 請求數(shù)量，I/O 請求通常為讀或?qū)憯?shù)據(jù)操作請求，關(guān)注的是隨機讀寫性能。

最后來簡單總結(jié)一下。性能調(diào)優(yōu)非常重要，不僅用戶體驗好，系統(tǒng)穩(wěn)定，更能體現(xiàn)出真正優(yōu)秀的編碼水平。我相信所有的小伙伴都能寫出跑的通的代碼，但至于痛不痛快，就需要在性能方面有所研究了。

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

感謝各位的閱讀，以上就是“性能調(diào)優(yōu)的標(biāo)準是什么”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對性能調(diào)優(yōu)的標(biāo)準是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！