服務器端編程的十大性能問題

問題一：過多的數據庫調用

    咱們發現常常出現的一個問題就是在每次請求/事務中存在過多的數據庫查詢。有以下三個場景做爲佐證

在一次事務上下文中所請求的數據比實際須要的數據多出不少。好比說：請求全部的帳戶信息而不是僅僅查詢出當前須要顯示的信息。

屢次請求一樣的數據。這種狀況一般發生在相同事務中的不一樣組件之間是彼此獨立的，而每一個組件都會請求一樣的數據。咱們並不清楚當前上下文中已經加載了哪些數據，最後只得屢次發出一樣的查詢。

發出多個查詢語句以得到某一數據集。一般這是因爲沒有充分利用到複雜的SQL語句、存儲過程等在一次批處理中獲取須要的數據所致使的。

 

問題二：過多地使用同步

    毫無疑問，同步對於應用中共享數據的保護來講是相當重要的舉措。但有不少開發者卻過分使用同步，好比在超大段的代碼中使用同步。在低負載的狀況下，這麼作倒沒什麼問題；但在高負載或是產品環境下，過分的同步會致使嚴重的性能與可伸縮性問題。

 

問題三：過分使用遠程調用

    不少庫都使用了遠程通訊。對於開發者來講，遠程調用與本地調用彷佛沒什麼區別，但若是不清楚遠程調用的本質就會鑄成大錯，由於每一次遠程調用都會涉及到延遲、序列化、網絡堵塞以及內存使用等問題。若是沒有通過深思熟慮而盲目使用這些遠程技術就會致使嚴重的性能與可伸縮性問題。

 

問題四：錯誤地使用對象關係映射

    對象關係映射爲開發者解決了不少負擔，好比從數據庫中加載對象以及將對象持久化到數據庫中。但與其餘任何框架同樣，對象關係映射也有不少配置選項須要優化，只有這樣才能適應於當前應用的須要。錯誤的配置與不正確的使用都會致使始料不及的性能問題。在使用對象關係映射框架前，請務必保證熟悉全部的配置，若是有機會，請深刻到所用框架的內核，這樣使用起來纔有保障。

 

問題五：內存泄漏

    託管的運行時環境（如Java和.NET）能夠經過垃圾收集器進行內存管理。但垃圾收集器沒法避免內存泄漏問題。「被遺忘」的對象依舊會佔據着內存，最終將會致使內存泄漏問題。當對象再也不須要時，請儘快釋放掉對象引用。

 

問題六：使用有問題的第三方代碼/組件

    沒有人會從頭編寫應用的所有功能。咱們都會使用第三方程序庫來加快開發進程。這麼作不只會加速產出，也增長了性能上的風險。雖然大多數框架都具備良好的文檔而且通過了充分的測試，但沒人可以保證這些框架在任什麼時候候都會像預期的那樣好。所以，在使用這些第三方框架時，事先必定要作好充分的調研。

 

問題七：對稀缺資源的使用存在浪費的狀況

    內存、CPU、I/O以及數據庫等資源屬於稀缺資源。在使用這些資源時若是存在浪費的狀況就會形成嚴重的性能與可伸縮性問題。好比說，有人會長時間打開數據庫鏈接而不關閉。鏈接應該只在須要的時候才使用，使用完畢後就應該放回到鏈接池中。咱們常常看到有人在請求一開始就去獲取鏈接，直到最後才釋放，這麼作會致使性能瓶頸。

 

問題八：膨脹的Web前端

    因爲如今的Web速度愈來愈快，用戶的網絡體驗也愈來愈好。在這個趨勢下，不少應用的前端都提供了太多的內容，但這麼作會致使差勁的瀏覽體驗。不少圖片都太大了，沒有利用好或是錯誤地使用了瀏覽器緩存、過分地使用JavaScript/AJAX等，全部這一切都會致使瀏覽器的性能問題。

 

問題九：錯誤的緩存策略致使過分的垃圾收集

    將對象緩存在內存中能夠避免每次都向數據庫發出請求，這麼作能夠提高性能。但若是緩存了太多的對象，或是緩存了不少不常使用的對象則會將緩存的這種優點變成劣勢，由於這會致使太高的內存使用率及過多的垃圾收集活動。在實現緩存策略前，請想好哪些對象須要緩存，哪些對象不須要緩存，進而避免這類性能與可伸縮性問題。

 

問題十：間歇性問題

    間歇性問題很難發現。一般這類問題與特定的輸入參數有關，或是發生在某個負載條件下。徹底的測試覆蓋率及負載與性能測試能在這些問題產生前就發現他們。