今年5月底，瑞士計算機世界雜志上刊登了Web性能診斷專家Bernd Greifeneder的一篇文章，文章列舉了其在過去幾年工作中所遇到的服務器端編程的十大性能問題。Andreas Grabner則在自己的博客上對這些性能問題給出了進一步閱讀的鏈接。希望這些問題與相關(guān)的延伸閱讀能為廣大的InfoQ讀者帶來一定的啟示。

　　問題一：過多的數(shù)據(jù)庫調(diào)用

　　我們發(fā)現(xiàn)經(jīng)常出現(xiàn)的一個問題就是在每次請求/事務中存在過多的數(shù)據(jù)庫查詢。有如下三個場景作為佐證：

• 在一次事務上下文中所請求的數(shù)據(jù)比實際需要的數(shù)據(jù)多出很多。比如說：請求所有的賬戶信息而不是僅僅查詢出當前需要顯示的信息。
• 多次請求同樣的數(shù)據(jù)。這種情況通常發(fā)生在相同事務中的不同組件之間是彼此獨立的，而每個組件都會請求同樣的數(shù)據(jù)。我們并不清楚當前上下文中已經(jīng)加載了哪些數(shù)據(jù)，最后只得多次發(fā)出同樣的查詢。
• 發(fā)出多個查詢語句以獲得某一數(shù)據(jù)集。通常這是由于沒有充分利用到復雜的SQL語句、存儲過程等在一次批處理中獲取需要的數(shù)據(jù)所導致的。

　　延伸閱讀：Blog on Linq2Sql Performance Issues on Database、Video on Performance Anti-Patterns

　　問題二：過多地使用同步

　　毫無疑問，同步對于應用中共享數(shù)據(jù)的保護來說是至關(guān)重要的舉措。但有很多開發(fā)者卻過度使用同步，比如在超大段的代碼中使用同步。在低負載的情況下，這么做倒沒什么問題；但在高負載或是產(chǎn)品環(huán)境下，過度的同步會導致嚴重的性能與可伸縮性問題。

　　延伸閱讀： How to identify synchronization problems under load

　　問題三：過度使用遠程調(diào)用

　　很多庫都使用了遠程通信。對于開發(fā)者來說，遠程調(diào)用與本地調(diào)用似乎沒什么區(qū)別，但如果不清楚遠程調(diào)用的本質(zhì)就會鑄成大錯，因為每一次遠程調(diào)用都會涉及到延遲、序列化、網(wǎng)絡(luò)堵塞以及內(nèi)存使用等問題。如果沒有經(jīng)過深思熟慮而盲目使用這些遠程技術(shù)就會導致嚴重的性能與可伸縮性問題。

　　延伸閱讀： Performance Considerations in Distributed Applications

　　問題四：錯誤地使用對象關(guān)系映射

　　對象關(guān)系映射為開發(fā)者解決了很多負擔，比如從數(shù)據(jù)庫中加載對象以及將對象持久化到數(shù)據(jù)庫中。但與其他任何框架一樣，對象關(guān)系映射也有很多配置選項需要優(yōu)化，只有這樣才能適應于當前應用的需要。錯誤的配置與不正確的使用都會導致始料不及的性能問題。在使用對象關(guān)系映射框架前，請務必保證熟悉所有的配置，如果有機會，請深入到所用框架的內(nèi)核，這樣使用起來才有保障。

　　延伸閱讀：Understanding Hibernate Session Cache、Understanding the Query Cache、Understanding the Second Level Cache

　　問題五：內(nèi)存泄漏

　　托管的運行時環(huán)境（如Java和.NET）可以通過垃圾收集器進行內(nèi)存管理。但垃圾收集器無法避免內(nèi)存泄漏問題。“被遺忘”的對象依舊會占據(jù)著內(nèi)存，最終將會導致內(nèi)存泄漏問題。當對象不再需要時，請盡快釋放掉對象引用。

　　延伸閱讀：Understanding and finding Memory Leaks

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

　　沒有人會從頭編寫應用的全部功能。我們都會使用第三方程序庫來加快開發(fā)進程。這么做不僅會加速產(chǎn)出，也增加了性能上的風險。雖然大多數(shù)框架都具有良好的文檔并且經(jīng)過了充分的測試，但沒人能夠保證這些框架在任何時候都會像預期的那樣好。因此，在使用這些第三方框架時，事先一定要做好充分的調(diào)研。

　　延伸閱讀： Top SharePoint Performance Mistakes

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

　　內(nèi)存、CPU、I/O以及數(shù)據(jù)庫等資源屬于稀缺資源。在使用這些資源時如果存在浪費的情況就會造成嚴重的性能與可伸縮性問題。比如說，有人會長時間打開數(shù)據(jù)庫連接而不關(guān)閉。連接應該只在需要的時候才使用，使用完畢后就應該放回到連接池中。我們經(jīng)常看到有人在請求一開始就去獲取連接，直到最后才釋放，這么做會導致性能瓶頸。

　　延伸閱讀： Resource Leak detection in .NET Applications

　　問題八：膨脹的Web前端

　　由于現(xiàn)在的Web速度越來越快，用戶的網(wǎng)絡(luò)體驗也越來越好。在這個趨勢下，很多應用的前端都提供了太多的內(nèi)容，但這么做會導致差勁的瀏覽體驗。很多圖片都太大了，沒有利用好或是錯誤地使用了瀏覽器緩存、過度地使用JavaScript/AJAX等，所有這一切都會導致瀏覽器的性能問題。

　　延伸閱讀： How Better Caching would help speed up Frankfurt Airport Web Site、Best Practices on Web Performance Optimization

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

　　將對象緩存在內(nèi)存中可以避免每次都向數(shù)據(jù)庫發(fā)出請求，這么做可以提升性能。但如果緩存了太多的對象，或是緩存了很多不常使用的對象則會將緩存的這種優(yōu)勢變成劣勢，因為這會導致過高的內(nèi)存使用率及過多的垃圾收集活動。在實現(xiàn)緩存策略前，請想好哪些對象需要緩存，哪些對象不需要緩存，進而避免這類性能與可伸縮性問題。

　　延伸閱讀：Java Memory Problems、Identify GC Bottlenecks in Distributed Applications

　　問題十：間歇性問題

　　間歇性問題很難發(fā)現(xiàn)。通常這類問題與特定的輸入?yún)?shù)有關(guān)，或是發(fā)生在某個負載條件下。完全的測試覆蓋率及負載與性能測試能在這些問題產(chǎn)生前就發(fā)現(xiàn)他們。

　　延伸閱讀：Tracing Intermittent Errors by Lucy Monahan from Novell、How to find invisible performance problems

it知識庫：服務器端編程的十大性能問題，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。