要想發揮系統的一個性能,必須是要讓系統發揮它的一個特別的優點,在實際中影響系統性能的緣由到底有什麼緣由呢?這一點咱們仍是須要了解清楚的,下面咱們來看看到底有什麼緣由會影響系統的性能?前端
一、日誌問題java
性能問題居然是日誌所帶來的問題,對於大多數日誌系統來講,隨着進程數量的增長,記錄日誌所須要的時間也會線性增長。在進程數量達到8個時,日誌記錄時間大約爲0.15s,很是影響系統的響應速度。所以日誌是一個比較重要的性能瓶頸,也是常常是被人忽視的重點。程序員
咱們可使用異步logger來去解決這個問題,同時當心設計logger所記錄數據的結構,以便進行後續的讀取和處理。算法
除此以外,logger重複記錄同一個錯誤是很是浪費性能的,咱們能夠將它設置爲只記錄第一次錯誤,最後是能夠設置一個計數器來去記錄錯誤發生的次數,這個方法也算是比較實用的。瀏覽器
二、函數設計問題緩存
在保證代碼的易讀性的同時,而後是提升代碼的性能可能會比較困難。服務器
實際上有不少技巧能夠在避免一些常見性能問題的同時,不會過多犧牲代碼的可讀性。例如,用C++語言寫函數參數時,能夠考慮使用引用或指針類型,這樣能夠避免在函數內生成臨時的數據結構,而且是不用返回數據。網絡
對於不少語言來講,函數返回Iterable就比直接返回Array要好,而且還將不會是影響易讀性。數據結構
三、通訊同步的問題架構
有作過網頁前端的朋友將會有必定的經驗,當瀏覽器訪問網頁時,速度可能會很慢,而再好再貴的服務器也解決不了這個問題,由於有些用戶仍是有可能用2G的手機網絡來訪問你的網站。
仍是有辦法能夠儘可能讓網頁加載速度快一點。好比優化圖片的大小,讓不一樣分辨率的屏幕加載不一樣大小的圖片,優化腳本加載順序,以及儘可能採用異步加載等實用的方法技巧。
四、沒有理解TCP的原理
若是是不理解TCP的原理就開始考慮微服務架構,在某些狀況下,如果遇到ACK延時可能致使每秒只能傳輸2-5個包。那麼形成這個現象的緣由是,TCP中的Nagle和TCP延時確認兩種算法有時會形成進程死鎖,而且是會影響微服務間的一個通信。
五、內存回收比較慢
這個問題它指是自動內存回收致使的問題。
使用自動內存回收的語言或者工具時,一次性分配過多的內存會增長內存回收的時間,這也將會是致使系統速度變慢。
六、數據結構的選擇
若是你是把超過1GB的數據存在一個數據結構裏,就須要當心內存的讀取速度了。這對於一個超過2GB的字典,java的HashMap比.NET的字典慢10倍以上。在別的一些狀況下,Java可能也比.NET快。
當在處理特別佔有內存的數據時,在選擇數據結構上須要進行仔細的一個斟酌,同時的話不要太依賴系統自帶的數據結構,這一點咱們是須要了解清楚的。
七、環境沒有升級到最新版的問題
實際上有多數的人是不肯意把軟件運行的環境或者系統升級到最新版,由於這些升級極可能會影響到正在運行的軟件或服務。若想但願提升系統的性能,是能夠先在測試環境中試一試。
同時是應該採起持續集成的工做流程,須要去常常更新代碼,寫完整的測試,此外試試看是否有一些bug能夠經過升級它所依賴的環境就獲得解決。
八、重複運行的代碼致使的問題
這是一個常見的問題,要了解清楚代碼能夠運行,和能夠有效率地運行是兩回事。一段代碼可能被重複調用了不少次,在表面上看起來卻沒有問題。好比每次須要一個文件就從磁盤讀取,當你用過以後並不緩存起來,這也將會是致使接下來訪問這個文件都是會變得很慢。
九、並行的緣由
咱們知道並行任務的通訊和同步須要系統開銷,而且這些通訊和同步自己並不必定是並行的。根據阿姆德爾定律(AmdahlLaw),若是5%的系統活動須要串行,不論是使用多少個處理器,系統最多也只能加速20倍。而通用擴展性定律(USL)則指出,在處理器達到必定數量後,並行系統的通信開銷會致使性能降低。
在創建並行系統時,儘可能避免引入共享可變的全局數據,一旦出現問題,幾乎是不可能知道是哪裏的代碼有問題,建議是使用不共享數據的方式構建並行系統,又或者是嚴格控制寫入數據的場景。
若是須要給算法加速,首先是要去考慮單線程的狀況,而後是再考慮複雜的並行狀況。
十、數據編碼問題
有不少的程序員是喜歡用JSON,XML,或Base64等編碼格式來傳送數據,由於這樣數據更具備可讀性,在debug時就很是的方便了。
但系統間的交互是不須要可讀性的,將二進制的數據轉換成文本再轉換成二進制不只消耗CPU,還消耗網絡帶寬。
實際上你能夠用Wireshark來debug服務器通訊,又或者是使用ProtoBuffer,Thrift等工具庫來優化通訊的過程。
總結:致使系統性能變慢的緣由還算是有比較多的緣由的,在實際的使用中能夠是根據出現的問題,適當的去採起有效的措施方法來提高系統性能,這是在系統運維中要掌握的基本技巧。